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ABSTRACT 


This thesis was undertaken to examine the post-development 
process of verifying the correctness of software programs, 
specifically to evaluate the effectiveness and practicality of 
several proposed methods of verification. Of interest were the 
degree to which utilization of a given method can be said to 
demonstrate correctness and the feasibility for general use of 
that method. The method of research was to study current 
literature concerning software testing and formal proofs of 
correctness, select a well-documented program of intermediate 
Size for experimentation, apply selected verification methods 
to that program, and finally to compare the results of the 
several experimental demonstrations of correctness. The 
experiments conducted included a proof of correctness and 
dynamic testing with test data cases selected by a condition 
table method, by path analysis, and by structural decomposition 


of the program. 
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I. INTRODUCTION 


This first chapter reviews the environment in which software 
verification methods are employed and presents generally accepted 


definitions and descriptions of software testing. 


A. THE SOFTWARE PREDICAMENT 

1. Scope of Software Development 

Ware Myers has characterized the current state of expanding 
programming applications as a serious software predicament (28). 
The cost of computer hardware has declined significantly over 
the last decade, making more and more applications feasible for 
automation. In 1973 it was estimated that between $15 and $25 
billion were being spent annually on software development and 
maintenance (3). The Department of Defense spent about $3 billion 
in 1976 on computer software (34), and has been doubling the 
number of functions performed by software every few years, 
primarily in converting weapons systems components from analog 
O digital. 

2. Problems in Software Development 

Unfortunately for the growing user communities, and 
despite the expectations raised with the advent of modern pro- 
gramming practices (MPP), all is not well with software 
development. | 
a. Our ability to estimate time and resources required 

for the design and development of software has not appreciably 
increased. 


b. Most major software projects have required that 
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special support tools be developed, that new automated testing 
aids be generated, or that a new language capability be acquired; 
in short, there is inadequate transfer of technology between 
projects within single organizations, and even less among organi- 
zations. 

c. An unreasonable share of software effort has been 
expended on maintenance of existing programs. Estimates of 75% 
or more of a company's programming effort being devoted to mainte- 
nance have not been uncommon. 

d. The rate of increase in programmer productivity has 
not kept pace with the introduction of improved management and 
programming methodologies, let alone with the rapidly increasing 
nardware capabilities; in fact, we are still struggling to learn 
to measure this productivity, 

e. The quality of software has been less than desired. 
While there is no agreement on how to quantify the quality of 
software, many shortcomings are apparent (4): software is still 
difficult to read, understand and modify; programs are frequently 
hard to use properly and easy to misuse; they are often lacking 
in sufficient generality to be used in several applications or 
transported to different machines; and program reliability has 
been disappointing. 

The applications planned for automation require bigger and 
more complex systems than ever before, Dijkstra pointed out 
that complex systems which are perhaps one thousand times larger 
than existing system cannot be constructed with the same 


techniques used to compose the smaller systems; order-of-magnitude 
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leaps in scale cannot be treated as gradual increases that can 

be handled by simple induction (10). A systematic and scientific 

method to accomplish functions of such magnitude is required. 
Improvements in the reliability of software (the extent 

to which programs can be expected to satisfactorily perform 

their intended functions) are desired without incurring the 

staggering costs of totally exhaustive testing. That reliability 

needs improvement seems obvious. The relative level of program- 

ming effort devoted to maintenance of existing programs bears 

testament to the existence of errors in programs presumably 

tested and certified correct prior to their release for use. 

Even diligent application of the modern programming practices 

by talented programmers has not necessarily produced reliable 

software. Gerhart and Yelowitz (15) identified errors in pro- 

grams that were published to demonstrate these MPP, errors in 

specifications, in construction, and in programs formally 


proven" correct. 


B. SOFTWARE ENGINEERING 
L. Current. Irends 

A discipline has arisen, referred to as software engi- 
neering, which draws from established principles of science 
and engineering in attempting to formally define a systematic 
approach to software development. While the goals of this 
discipline are broad in scope, the application of software 
engineering toward attainment of correct software is of 


particular interest, 
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Recent trends in software engineering have emphasized the 
role of design and implementation in preventing errors over 
the role of testing to detect errors for correction. These 
techniques include: 

a. More thorough analysis and definition of requirements: 
The lack of adequate system specifications has been a major 
cause of software shortcomings (12). 

b. Modular design of programs. 

c. Top-down design and implementation techniques. 

d. Management practices such as the use of the team 
concept (possibly including the chief programmer team concept), 
project workbooks, formal documentation requirements, formal 
and peer review, and structured walkthrough of code. 

e. Structured programming: This concept is at the core 
of modern programming practices. While many managers complain 
that they encounter resistance in implementing structured pro- 
gramming in their organization (5), there is growing data to 
Support the proposition that structured programming techniques 
can produce more reliable and more cost effective software 
systems (28). 

2. Needstor Post-Development Testing 

The experience of the research reported in later chapters 
of this thesis confirmed the need for greater relative emphasis 
on design and implementation techniques as compared to verifi- 
cation techniques. Much of the process of constructing a formal 
proof of correctness of the sample program selected for experi- 


mentation was clearly a duplication of the design and implementation 
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effort; it was necessary to analyze the completeness and con- 
sistency of the program specifications, verify the particular 
modular design selected, justify the control flow of each pro- 
cedure, and determine the reasoning behind the choice of 
particular stopping criteria for program loops. To a somewhat 
lesser extent the same was true of the most rigorous of the 
dynamic testing strategies employed (Chapter III, Section C). 
The duplication of effort is simply not cost effective. 

The successful and widespread use of as yet undeveloped 
techniques that will ensure development of correct software 
programs lies many years ahead. For the foreseeable future, 
programs under development will need to be subjected to an 
effective and practical ex post facto verification process. 
Diligent application of existing program testing techniques has 
been shown to enhance the software development process (1,2,6). 
Significant efforts are required in applying the discipline of 
software engineering toward refinement or replacement of the 


verification methods now in use. 


C. DEFINITIONS IN SOFTWARE TESTING 

Methods of testing or proving the correctness of software 
have been developed until quite recently on an ad hoc basis, to 
fill particular needs in the field rather than to build a 
complete scientific model for the verification process. The 
terms used to describe the activities involved in demonstrating 
correctness have likewise evolved sporadically. The following 


definitions are widely but not universally accepted. 
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1. Correctness of Software 

The central issue in software testing, verification, 
validation, or similar terms is a demonstration that the software 
at hand is correct; i.e., that the given software system produces 
the intended results. The assertion that a program is correct 
is in effect a statement that it performs precisely those func- 
tions, and only those functions, called for in its specifications, 
and furthermore that its specifications are an accurate repre- 
sentation of a design suitable to satisfy the intended require- 
ment. The term "correctness' has a connotation inclusive of and 
stronger than the notion of reliability of software, which was 
defined earlier as the extent to which programs can be expected 
to satisfactorily perform their intended functions. A thorough 
demonstration of correctness involves more than showing that a 
program satisfies some written specifications; it involves an 
analysis of the completeness, clarity, and consistency of the 
specifications as well. 

2. Debugging 

This term has frequently been used synonymously with 
testing, but should be distinguished in the following sense: 
testing is a process to uncover errors, while debugging begins 
when an error has been detected and is the process of isolating 
and correcting these known errors. A succinct statement of this 
distinction 1s: 

When debugging is completed the program definitely 


solves some problem. Testing seeks to guarantee 
that it is the problem that was intended (18). 
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Se esting 


Testing has just been distinguished from debugging. In 
Reference 24 five major activities in testing were defined, using 
ene terms most commonly accepted in practice: 

2.. Věeritication is the process of establishing logical 
correctness of a program (i.e., correspondence with formal require- 
ments) in a test environment. Verification is typically accom- 
plished by actual program execution using selected test data. 
This process of dynamic execution is the single activity most 
often intended by use of the general term testing. 

b. Validation is the process of establishing logical 
correctness in some given external environment, although not 
necessarily in the operational environment. 

C. Proving is the mathematical establishing of logical 
correctness without regard to the environment; it does not 
involve program execution. 

d. Certification is an organizational endorsement that 
a program Heats certain standards of correctness and effectiveness 
in a useful environment. 

e. Performance testing is the demonstration of non- 
logical properties, usually execution timing and throughput 
capability. 

4. Verification and Validation 

Verification and validation is a currently popular term 
used to describe the processes involved in testing software 
prior to user acceptance; used as such the term actually encom- 


passes to some degree all five of the above testing activities 





(with the frequent exception of proving). 
5. oCales of Testing 

During the development and operation of a software system, 
differing scales of testing must be performed. Traditional 
scales of testing are unit testing, integration testing, and 
regression testing. 

a. Unit Testing 

Unit testing is the testing of the independent modules 

comprising the functional decomposition of a large system. Testing 
at the unit level involves examination of the internal logic of 
the module to ensure that the module*s effects on the larger 
program containing it are consistent with those effects required 
by the specification, and verification of the assumptions made 
within the module about the larger program. Because specifications 
are frequently ambiguous, unit testing often results in reexami- 
nation of the unit specification. 

The two methods employed in unit testing are functional 
(black-box) tests, which are based on no knowledge of the inter- 
nal structure of the program, and logical tests which are based 
on program structure. Selection of test data which are appro- 
priate for an ideal test (as described in Chapter II, Section A) 
is difficult or impossible for black-box testing because it is 
impossible to distinguish data that are treated similarly or 
differently internal to the black-box. Therefore program veri- 
fication tests by the developer are nearly always based on pro- 
gram structure. Acceptance testing by the user is generally 


functional in nature of necessity. 
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D. Integration Testing 

Integration testing is conducted to determine the extent 
to which a system meets its specifications in an environment 
Similar to its working environment. The focus of integration 
testing is on module interaction as opposed to internal module 
operations. When unit testing has been conducted thoroughly 
beforehand, integration testing is primarily a verification that 
modules do not modify those relationships in the environment 
that the specification states must be preserved (e.g., that pro- 
tected portions of memory have not been affected and that global 
variables have not been modified in an undesirable or unantici- 
pated manner), and a thorough test of the consistency of the 
Speci tiGation itself.’ Were the techniques of formal defination 
of requirements and automated verification of specifications 
more developed, integration testing would be less than the 
crucial and expensive effort it so often has become. 

The relationship between unit and integration tests is 
formalized by the following theorem which is the basis for 
demonstrating the correctness of software by testing or proving: 

If it can be demonstrated that each module in 

a system meets its specifications assuming only 
that all submodules meet their specifications, 
then the entire system is correct (16). 

It should be noted that the demonstration required by the 
above statement is essentially a verification that the inter- 
actions of modules are consistent with the specifications. 

There is controversy over the best strategy for sequencing 
unit and integration tests. The classical strategy of bottom-up 


testing proceeds from unit to integration tests as lower-level 
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modules are completed, and requires test program drivers to run 
lower-level module tests until the calling modules are ready to 
be incorporated. Common criticisms of this strategy are the 
duplication of effort in writing driver programs, the cost in- 
volved since execution of higher-level modules involves reexecu- 
tion of the lower modules, and most severely the fact that inte- 
gration errors if present are discovered at a late stage in 
development, thus inflating the cost of their correction. 

The top-down testing strategy is much heralded as an integral 
part of the top-down design technique, büutitorscloictio pracbrceed 
Its benefits are purported to be the early detection of specifi- 
catlon errors relating to interfacing, since the high-level pro- 
gram skeleton is coded and executed first, with simple dummy 
programs required as sub-program stubs. These stubs are to be 
heplaced by the actual lower-level modules as they are written, 
thus facilitating the check-out of new modules one at a time 
while continually verifying the correctness of module interfaces. 
In introducing the concept of a built-in package of "test pro- 
cedures"! deliverable with a software product, Panzl contends 
that neither of the above goals are well served by the top-down 
Strategy (30). He states that top-down testing discourages 
thorough testing of lower-level modules because they are never 
executed directly; in fact, it is often difficult to find an 
input data combination that will force execution of a desired 
submodule. 

In practice a mix of top-down and bottom-up strategies has 


been used. Unfortunately, a common choice of strategies is to 
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defer all testing until the entire system can be tested. This 
all-at-once strategy is costly in execution time because all 
modules must always be present, and costly in effectiveness be- 
cause the intellectual task of isolating errors is greatly magni- 
fied when a systematic strategy 1s missing. However, it is the 
most prevalent testing strategy today (30). In fact, the experi- 
ments in testing and proving which are reported in the following 
chapters of this thesis were performed in an all-at-once fashion 
by virtue of the fact that a program which had completed develop- 
ment was the subject of the experiments. Even so, elements of 
bottom-up testing were apparent in several of the strategies used. 
C. Regression Testing 

Regression testing 1s the reverification and revalidation 
of software after adding new capabilities or after performing 
maintenance to correct errors discovered in operation: Its 
purpose is to verify that the desired modification and none other 
has been made, Regression testing has until recently received 
very little formal attention (12), which is puzzling in light 
of the previously mentioned estimates of the percentage of 
programming effort devoted to maintenance. A simple management 
technique to enhance regression testing is to ensure that the 
test cases produced during development testing are collected 
and documented as a package, and maintained to be reexecuted 
after maintenance. If extensive maintenance is performed, addi- 
tional analysis of the thoroughness of test achieved with the 
saved data should be conducted. While the test procedures 


suggested by Panzl (30) add to the effort of development, their 
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value at regression test time merits careful consideration of 


the idea. 


D. APPROACHES TO DEMONSTRATING CORRECTNESS 

As suggested earlier, testing is a discipline that has been 
learned through application, with little formal basis until 
mery recently, The first major collection of testing concepts 
resulted from a 1972 conference at the University of North 
Carolina, the proceedings of which were published in book form 
by W. C. Hetzel (18). The first significant attempt to establish 
a mathematically-based theory of program testing was a paper by 
John B. Goodenough and Susan L. Gerhart (17); this theory is 
discussed in Chapter II. 

In the development of testing methods, two complementary 
approaches arose, static analysıs and dynamic testing. Methods 
that have been employed in an. attempt to show correctness have 
ranged from purely static (e.g., formal proof of correctness) 
to purely dynamic (e.g., execution of the programs with randomly 
selected test data), although usually a combination of the two 
approaches has been used. 

ls Static Analysis 

a. Capabilities 
Static analysis refers to a wide range of activities 
that can be performed without program execution (although more 
and more such activities involve automated analysis of source 
programs by software tools). Quite often static analysis is 
perfomred prior to live testing to help in test planning and 


test data preparation. The technique can in itself detect errors 
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in logic (such as uninitialized variables) and questionable 
software practices (such as initialized but never referenced 
variables). It can also be used as a means of enforcing pro- 
gramming standards. 

The most familiar form of static analysis is program checking, 
or desk checking. While automated static analysis techniques 
of significant capability are being developed, thorough desk 
checking is still an efficient method for insuring software 
correctness. When formalized by management in effective peer 
review or structured walkthrough policies, program checking is 
"very effective'' in reducing errors (1). Program checking can 
detect syntax errors, undeclared variables, unreachable program 
segments, etc. 

Directed graphs of program control flow and data flow are 
common tools of static analysis, and are the basis for the path 
analysis techniques of dynamic testing. Graphs of data flow 
lend themselves to detection of errors in initialization and 
referencing of data. Control flow graphs provide visual evidence 
of program adherence to structured programming practices and 
offer several measures of program complexity. Considerable study 
of the relationship between program structure and complexity 
and resultant error characteristics has been conducted at the 
Naval Postgraduate School (most recently reported in Ref. 33). 

A strong relationship has been found to exist between complexity 
and errors, suggesting that complexity measures may be used to 
establish programming standards (note that constructs of 


structured programming have lower complexity measures than 
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Bon-structured censtructs) and to indicate how to allocate 
scarce testing resources, 

b. Automated Aids 

Particularly when dynamic testing is to be performed 

Zen. the number of paths tested as a criterion, static analysis 
techniques are used to aid in developing test cases, frequently 
by pautomation. Fairley (12) suggests that static analysis 
algorithms (including cross-reference tables, numbers of 
öc currence of statement types, number of Subprogram calls, graph 
analysis, etc.) can and should be included in compilers. 
Ramamoorthy et al. (32) discuss the techniques and problems 
involved in automated generation of test data inputs selected 
to satisfy varying requirements for coverage of the branches 
of a program graph, and describe a prototype generator included 
in their Fortran Automated Code Evaluation System (FACES). 

C. Limitations 

Whether test data is generated manually or by auto- 

mated means, there is unfortunately no reliable way of automating 
the computing of the correct output. Needless to say, dynamic 
testing presupposes a known (or at least bounded) output, and 
specifications must be available for each program tested. A 
limitation in the degree of testing which is feasible is fre- 
quently imposed by the difficulty of determining the desired 
output. 

A serious limitation of static analysis, and particularly 
of test case generators, is the decidability problem (12). 


Algorithms may be easily written to identify all syntactic 
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paths of control flow in a program, but it is not possible to 
algorithmically determine the semantic paths (those syntactic 
paths which can in fact be executed for some set of input data). 
Therefore it is not possible for all programs to determine 
whether some statements (including termination statements) can 
be executed for any input data. In these cases dynamic testing 
or the more difficult techniques of symbolic execution or proofs 
of correctness are often used to decide the question. 
2. Dynamic Testing 

Dynamic testing is the process of actual program execu- 
tion to provide evidence upon which some conclusion may be 
reached as to the correctness of the software. Applications 
of theoretically-based testing methods (as described in Chapter 
II) have not yet countered Dijkstra's pronouncement that "Program 
testing can be used to show the presence of bugs, but never to 
show. their absence!" (10). Nonetheless, dynamic testing has 
been and will remain the most common evidence proffered to show 
program correctness or reliability. 

a. Selecting Test Cases 

The critical activity during dynamic testing is the 

selection of test cases. Intuitively it is desirable to select 
a set of test cases which are representative of the actual input 
domain the program will have to contend with during operation. 
The principle guide in selecting test cases has been to test 
for the likely kinds of errors in the program, particularly in 
the program modules deemed most critical to proper program 


operation. Since it is not possible to anticipate all the 
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possible errors, it is unlikely tnat this principle alone can 
be relied on to select a suitable set of test data. Selection 
of a data set truly representative of the input domain is parti- 
cularly difficult without knowledge of the internal structure 
of the program (i.e., when doing black-box testing), because it 
is then impossible to distinguish data that are treated similarly 
internally. Knowledge of the program structure can be used to 
identify the complex portions of the program which should be 
subjected to the most thorough testing, and to help identify 
the groups of data that are handled similarly and thus aid in 
selecting those cases representative of certain subsets of the 
input domain. However, use of this knowledge is of limited value 
in that there is no certainty that the program structure is a 
Gourect representation of the conditions required for correct 
operation of the program (16). 
b. Thoroughness of Tests 
The thoroughness of test, or degree of test coverage, 

is intended to provide a measure of the reliability of the 
testing process. The more thorough the test, the less probable 
that undetected errors remain. Unfortunately, no perfect quanti- 
tative measure of test thoroughness has been recognized, although 
it is «clear that the criteria used to select test cases will 
determine the thoroughness of test. 

Typically, estimates of test thoroughness have been based 
on a count of the source statements executed or the program 
control paths traversed. While a test which causes the execution 


of all program source statements may appear thorough, there are 
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numerous counterexamples which demonstrate the actual lack of 
thoroughness (for example, in Ref. 22). Since there are typically 
an infinite number of possible sequences of statement execution, 
any finite tests which execute each program statement at least 
once cannot be said to have tested all possible sequences, and 
thus may fail to reveal all program errors. The path TER 
strategy of dynamic testing involves execution of selected con- 
trol flow paths in the program under test. Because the number 
of control flow paths may be very large or infinite (due to the 
presence of loops), practical path analysis strategies are 
limited to execution of some subset of the total paths. Huang 
"defined a "minimally thorough" test as one which caused at least 
one traversal of every branch or arc in the program's control 
flow graph (flowchart) (22); however, such a test cannot assure 
detection of all errors. In fact there is no agreement as to 
what an adequate measure of thoroughness may be (traverse each 
arc twice, traverse all possible arc pairs, etc.). Nonetheless, 
it has been shown that for many programs (65% of a small survey 
of eleven programs conducted by Howden), path analysis criteria 
are “almost reliable" (21). Given the alternatives, testing 
based on path analysis is today a sound choice, particularly 
when accompanied by careful program checking and a structured 
walk-through of the design itself. 

The discussion in Chapter II of a theory of testing further 
examines the critical matter of thoroughness of tests. 

c. Automated Aids 


Automated aids to support dynamic testing include 
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the experimental test case generators discussed in the section 
on static analysis, and programs which compute the degree of 
coverage of the program graph according to the given path analysis 
criterion. Pimont and Rault (31) describe an implementation of 
such a technique, with a more ambitious coverage criterion than 
most of the path analysis techniques. 

The insertion of software counters in the target branches, 
a relatively simple form of program instrumentation for testing, 
assists in test data selection by providing feedback as to the 
coverage obtained from each set of input data (22, 23). A common 
form of program instrumentation is the use of assertion statements 
expressing the relationships among data which should hold at 
various nodes in the program. During execution the assertions 
are evaluated to check their validity. Program instrumentation 
can also be used to perform data flow analysis by setting state 
flags as variables are defined, referenced, and undefined, and 
noting any illegal state transitions. Program instrumentation 
requires much of the information normally available in a compiler; 
therefore it is becoming a feature of experimental test facilities 
that program instrumentation be performed as a compiler option. 

More extensive instrumentation of the source program is 
involved in execution analysis or execution histogram systens. 
Such systems have as a goal the creatıon of a data base of pro- 
gram execution information that can be output in batch fashion 
or remain available for interactive query. These systems facili- 
tate source language debugging, can provide control and data 


flow information, environmental information, assertion checking, 
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tracebacks, etc. The information can aid static analysis and 
dynamic testing (path analysis or other). There are drawbacks 
to these systems: very high cost, both in development and use, 
lack of generality (machine and language dependent usually), 
and the attendant problems of handling the large data bases that 
can be created. Fairley describes an Interactive Semantic 
Modeling System (ISMS) implemented experimentally for application 
to Algol 60 prgrams (11). The Naval Sea Systems Command has 
successfully used a software processor AUDIT to aid program 
verification and to monitor adherence to structured programming 
standards (71). i 
Program instrumentation in most cases involves modification 
of the source code, and generally incurs an unacceptable per- 
formance penalty (as does the evaluation of assertions). There- 
fore it is common to remove such instrumentation from production 
programs, and to repeat dynamic testing with the optimal set of 
test data to ensure that program performance remains correct. 
There are two simpler automated aids to dynamic testing 
that should be mentioned. Generators of random test data are 
not uncommon; although random data do not generally provide a 
thorough test, they are easy to obtain. While automated compu- 
tation of the expected results of tests is not feasible (because 
such computation amounts to automation of the function of the 
program under test and is the object of verification), automated 
comparison of actual results with the expected results is practical, 
and useful as a labor-saving aid. The expected results are 


typically computed by hand or determined from historical data, 


28 





or bounds defining reasonable results are established if compu- 
mation is overly difficult. 
d. Limitations 
Limitations to the effectiveness of dynamic testing 

at ensuring the correctness of software were evident in the dis- 
cussion of the difficulty of determining a reliable measure of 
‘test thoroughness. An additional drawback to any form of dynamic 
testing is the cost both in time and ON 

Testing or verification techniques include several indepen- 
dent or even contradictory methods, due to the infancy of soft- 
ware engineering and program testing theory. The rationalization 
ef this apparent inconsistency lies in the realization that, 
given the present understanding of software, nearly every soft- 
ware development is a unique and individual design. Cerification 
of such programs requires the testing team to be familiar with 
a variety of testing methods and tools, and to judiciously apply 


those which seem best suited to the task at hand. 
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LI. NATURE OP THE PROBLEM 


A. A THEORY OF TESTING 
As alluded to in the first chapter, a tentative theoretical 
basis for the testing of software has been formulated by Good- 
enough and Gerhart (17). That theory is capsulized in this 
section. 
1. Types of Errors 
Testing is a process of collecting and analyzing evidence 
relating to the presence of errors. To reach a meaningful con- 
clusion as to the presence of errors, the nature of errors must 
be clear. On a logical basis, errors can result from failure 
in implementing the specification (construction errors), failure 
DL the specification to accurately reflect the design, failure 
of the design to adequately solve the requirements that are under- 
stood, or failure to identify the real requirements. Each of 
these logic errors will ultimately appear as an inappropriate 
effect produced by ne implementation, namely as: 
a. missing control flow paths, 
b. inappropriate path selection, or 
c. inappropriate or missing action on a path. 
Recognizing the types of inappropriate effects that may be 
caused by errors, the problem in testing 1s to select test cases 
that can show that these errors do not arise. As mentioned ear- 
lier, a common criterion for selecting test data is to choose 
data which will exercise each arc or branch in the directed graph 


representing the program at least once. Because logic errors, 
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particularly specification, design, and requirements errors, may 
be manifested by missing paths, it should be obvious that this 
criterion alone cannot select test data that will thoroughly 
test a program. 

2. Criteria for Test Case Selection 

Goodenough and Gerhart defined an ideal test as one which 

succeeds only when a program contains no errors. They defined 
two predicates about a criterion C for selecting test cases that 
1f satisfied are sufficient to establish that any complete test 
is an ideal test (a complete test is one using the criterion C 
to select a set of test data T which are subsequently used to 
dynamically test the program). These predicates, RELIABLE(C) 
and VALID(C), are defined as follows. A criterion is reliable 
only if all complete tests yield the same (not necessarily 
accurate) result; that is, if one complete test is successful 
(no program errors are revealed), then all complete tests must 
be successful, and if one complete test reveals an error, all 
must reveal that error. Reliability of criteria refers to con- 
sistency; using a reliable criterion, a second complete test is 
redundant as it can provide no new information. A criterion is 
Walid only if for every error that can exist in a program there 
is (at least) one complete test that can show the presence of 
the error. 

The concept of reliability of a criterion for selecting test 
cases is not to be confused with the earlier definition of soft- 
ware reliability as a measure of the extent to which programs 


satisfactorily perform their intended functions. 
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The fundamental theorem of testing that Goodenough and Gerhart 
have suggested is simply that there exist some criterion C for 
selecting test data and some subset T of a program's input domain 
D such that when it is shown that a test using test data T is 
a complete test and that the criterion C is both reliable and 
valid, then success of the test implies that the program is 
SU Lec Le 

Stated formally, the theorem is: 

(3 TED) (3C) [CCOMPLETE (T ,C)ARELIABLE(C) 

ANALID(C) A SUCGESSFUL(T) ) => (¥deD) OK(d)}; 


where COMPLETE (T,C) 1s a predicate indicating that the test T 
is complete according tOo the criterion C, and OK(d) is a pre- 
dicate indicating that program execution with the element d 
from the input domain D produces the results required by the 
program specification, 

The theorem is not profound; its proof is simple and is 
assured by the convenient definitions of reliable and valid 
ersterja, If there- is some complete test capable of revealing 
any error (valid criterion) and if all complete tests yield the 
Same result (reliable criterion), then clearly any complete 
test based On a valid and reliable criterion must correctly 
demonstrate the presence or absence of errors. 

For the skeptic, a proof of the theorem may be written as 
follows: 

- As to the existence of such a T&D and criterion C, either 
the program 1s correct or ít is not: If it is correct, then a 


criterion C such that a complete test T is (d), where d is any 
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element of D, will satisfy the theorem. If the program is not 
correct, there is some element d€D such that -40K(d). Then a 
criterion C such that T={d} is a complete test. In either case, 
the required conditions are satisfied, and the criterion and 
test set exist (the challenge for the program tester is to dis- 
cover them). 

- As to the theorem's implication, assume the truth of the 
hypotheses and assume (AdeD) — OK(d); i.e., assume the theorem 
is false. 

- Then VALID(C)> (3TsD) [COMPLETE (T,C) A ~ SUCCESSFUL (T)]. 

- Then RELIABLE(C)=>"all complete tests fail." 

- But this contradicts an hypothesis of the theorem, namely 
=D SUCCESSFUL(T). 

Ecbnd of proot. 

Use of the theorem is not an easy matter. A criterion for 
selecting test data must be chosen and that criterion must be 
proven reliable and valid. Techniques using dynamic testing to 
"prove" software correctness will be practical only if the proofs 
öf criterion reliability and validity are simpler to construct 
and at least as convincing as proofs of program correctness. 
The experiments reported in this thesis examined some aspects 


of applying the above theorem. 


Bess 7 SATISEYING> THE PREMISES OF THE THEORY 
l. Formal Proofs of Correctness 
A degenerate application of the above fundamental 
theorem of testing is selection of a criterion C such that a 


complete test is complete only if T is the null set; in this 
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case, no testing is done. The criterion C is clearly reliable 
Since there can be no tests. To show that C is valid (any 
possible program error will be revealed by at least one comnlete 
test), 1t must be shown that the program has no errors at all. 
Application of the theorem with such a criterion is therefore 
equivalent to a proof of program correctness. Such a proof 
was constructed for the sample program of this thesis (Chapter 
EV Seetion B). | | 
2. oymnpolic Executron 

symbolic execution is a technique whereby symbols are 
used as input values rather than real data elements and the 
program is symbolically executed by replacing all data operations 
with symbolic operations. Intermediate results then are compu- 
tational expressions of the input symbols rather than data 
objects. In the case of conditional branching in the program, 
logical statements on the input symbols, called path conditions, 
describe the conditions under which a given control path may be 
traversed. Program correctness is shown by proving that at 
termination the constraints of path conditions imply that the 
computational expressions of input symbols are equivalent to 
thosé required by the program output specification. That proof 
and the required proof of similar intermediate theorems con- 
stitute a general theorem-proving problem; automated theorem- 
proving capabilities are currently quite limited, and proving 
the theorems by hand is quite tedious. This drawback restricts 
the practical use of formal proofs of correctness as well. A 


system for symbolic program execution is described in Ref. 8. 
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Symbolic execution is related to the theorem of testing in 
that the criterion C is to choose input symbols satisfying the 
program's input specification; to show the reliability and 
validity of C, it must be shown that the output specification 
of the program can be expressed as a computational expression of 
input symbols and that the intermediate expressions are valid 
over the entire domain of values for input symbols. 

The technique of sumbolic execution was not directly applied 
in these experiments; however, the experiment using test data 
execution and the principle of distributed correctness (Chapter 
IV, Section C) relied on some of the ideas of symbolic execution. 

5. Test Data Execution 

Clearly one ideal test is execution of the program for 
every member of the program's input domain. Since most input 
domains are infinite, this test is usually impossible and nearly 
always prohibitively costly, and can therefore hardly be called 
ideal in any practical sense.  Goodenough and Gerhart used in 
Reference 17 a '"condition table method'" to select test data for 
program execution. While they were not able to conclusively 
prove the reliability or validity of this method as a selection 
criterion, they attempted to show that they did identify equiva- 
lence classes covering the input domain of an example program 
and choose a representative of each class which by induction 
tested each member of that equivalence class. The condition 
table method was incorporated in an experiment of this thesis 


inseonjunction with the distributed correctness principle. 
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Test data selection techniques such as path analysis and 
independent sub-structure analysis are also attempts to identify 
equivalence classes in the input domain, while again only in- 
formally trying to establish criterion reliability and validity. 
These techniques were used in the experiment reported in Chapter 
IV, Sections D and E; in each case, however, 1t was not possible 
to determine whether the equivalence classes identified actually 
covered the input domain until comparison with the results of 


other experiments. 
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III. EXPERIMENTAL PROCEDURES 


An example program was selected for experimentation, and 
several verification methods were applied to demonstrate the 
correctness of the example program. The hours of effort required 
for each method were recorded and qualitative assessments were 
made about the degree of difficulty of using each method. The 
example program and the methods employed are described in this 
chapter; the actual results and a comparison of the methods is 


presented in the next chapter. 


A. THE PROGRAM AND INTUITIVE TEST DATA 
1. Origin and Description 

Reference 20 is a report of an experiment in software 
error occurrence and detection conducted at the Naval Post- 
graduate School. Four programming projects were undertaken and 
data were recorded on the man-hours expended in each development 
phase, time of detection and occurrence of errors, and man-hours 
expended correcting errors. Errors were classified according 
to the development phase in which they occurred and by descriptive 
types, and were analyzed with respect to development phase, 
correction time, and program complexity. 

Project number one of Reference 20 was chosen as a program 
for experimental verification. The subject program reads and 
processes a variable length string of text characters, recording 
all occurrences of palindromes (sub-strings which read the same 
forward or backward), including overlapping palindromes and 


omitting palindromes entirely included with another. The program 
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was written in Algol-W to run under OS/MVT. It contains 141 
source statements and consists of the main program and ten 
procedures, five of which are significant to the palindrome- 
finding algorithm; the remaining five are called to print the 
results. The original program development required 5.0 man- 
hours in the design phase, 7.0 in the coding phase, 4.0 in 
debugging, and 5.8 hours in the original testing phase. 

2. Program Listing 


Figure 1 is a listing of the palindrome program. 


38 





begin 

Been: This program finds palindromes within a character string 
of maximal iength = 256. 
Minimum string length is 2. 
All input cards will be listed. 
The program will produce a list of only those palindromes 
which are not entirely included in a larger palindrome; 


comment data declarations; 


string(1) array text(1::256); comment contalns character 
string; 
string(89? cardbuffer; comment io buffer for cards; 


Integer array begin_-of_palindrome, end_of_palindrome(1::256); 

luteger cardlimit, length_of_text, bufferposition, card_counter, 
palindrome_counter; 

integer ix, JX; comment index variables; 


comme nt initialization; 


procedure initiaiize; 
comment initialize all variables, read length_of_text, write texti; 
begin 
textl; 
JxX:= 1; 
palindrome—counter:=1; 
cardiimit: =80; 
intfieldsize:=5; 
readí length_of_text); 
if (Clength_of._text < 2) or (length_of_text > 256)) then 

begin 

write( "illegal Input:*, 

" length of input string is: ",length_of_text); 

assert( false); 

end; 
cardbuffer:=" "; 
end initialize; 


comment utilities; 


procedure blank. lines(integer value n); 
comment write n blank lines; 


begin 
integer i; comment local counter; 
assert (n>9); comment safety check; 


for i:=1 step 1 untll n do write(" "); 
end blank_lines; 


procedure texti; 

begin 

writet "Find ali palindromes within the foilowiug string:"); 
blank..lines(2); 

write( "Card Text"); 

writel "Number"); 

blank_iines(i); 

end textl; 
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procedure text2; 

begin 

hlank_llnes(2); 

write( "The foliowing palindromes have been detected: "); 
blank_lines(I1); 

write( "Palindrome Degin End"); 

write( "Number Card Character Card Character"); 
write( " Number Position Number Position"); 


end text2; 


procedure text3; 

begin 

write( "No paiindromes fonnd. End of run."); 
end text3; 


procedure read_and_write_input_cards; 
comment read input cards according to given length_of_text; 
begin 
integer number of input cards; 
number of input. cards:=( length. of „text - i) div cardlimit + 1; 
ix ši; comment reset text index; 
for card- counter:=1 step | until number of input cards do 
begin 
writelcard_ counter); 
writeon(" "); 
readcard(cardbuf fer) ; 
writeon(cardbuffer) ; 


bufferposition:=0; comment reset index; 
while ((ixc=length of text) and (bufferpositionccardlimit)) do 
begin 


text(ix):-cardbuffer(bufferpositionl1); 
ix:=ix+l; 
bufferposition:=bufferposition+l; 
end; commeut done for ail characters on a card; 
end; comment done for ail cards; 
end read.-and wrlte input. cards; 


procedure write all palindromes; 
comment list all palindromes being found; 


begin 
integer i,J: comment local counters; 
text2; 
for i:=1 step ]| until Jx-1l do 
begin 
if end.of.pniindrome(i) --90 then 
begin 
write(palindrome_counter) ; 
writeon(" "); 
writeont ((begin-of_palindrome(i)-1) div cardlimit) + 1); 
writeon(" "); 


if (begin-of_palindrome(i) rem cardlimit = 0) then 
writeon(cardlimit) 


else 

writeon((begin of palindrome( i) rem cardlimit)); 
writeon(" ad 
writeon(€((end_of_palindrome(i)-1) div cardlimit) + 1); 
writeon(”" n) 
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if (end of palindrome( i) rem cardlimlt =0) then 
writeonícardlimit) 
else 
writeon((end_of_palindrome(i) rem cardiimit)); 
write(” DE. 
for J'-begin.of.palindrome(i) step | 
until end of palindrome( 1) do writeon(text*tJ)); 


blank_I Ines( 1); 
palindrome_counter:'=palindrome_counterti; 
end; comment end if; 
end; comment done for all palindromes; 
end write _all_palindromes; 


comment subroutines; 


precedure palindrome—check; 
comment find ail palindromes within given text string; 
begin 
comment scan text from left to right; 
for ix:=2 step i untii length of text do 
begln 
if text(ix-1) = text( ix) then continue checking((ix-i), ix); 
if ix ~= 2 then 
if textCix-2)=text(lx) then continue checking((ix-2),ix); 
end; 
end palindrome check; 


procedure continne checking (integer value flrst,last); 
comment Given first and last as pointers to a palindrome 
of size 2 or 3, this procedure checks whether or not this 
palindrome is included in a larger palindrome; 
begin 
logical palindrome; 
pallndrome:=true; 
while ((first>i) and (last< length_of..text) and (palindrome= true)? do 
begin 
if text(first-i) = text(last+i) then 
begin 
comment larger palindrome found; 
first:-first-i; 
last:=last+1; 


end 
clse 
begin 
palindrome:=false; comment largest palindrome found; 
end; 
end; 


record_palindrome(first, last); 
end continue_checking; 
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procedure record—_palindrome (integer value first, last); 


comment Record only max length palindromes. Flag previously 
recorded palindromes if they are included in the pal lndrome 


specified by first and iast. 


Jx was initialized to ff. After completion jx points to the 
next entry in begin_of_pallndrome and end_of_palindrome; 
begin 
integer i; comment local counter; 


logical entry; 
entry: =true; 
for i:=i step 1 until yx-l do 
begin 
if ((first>=begin_of_palindrome(li)) 
and (last“=end of palindrome(1))) then 


begin 
comment  Palindrome is entirely included in a previonsly 
recorded paiindrome. No entry required; 
entry:-false; 
end 
else 
begin 
if ((begin_of_palindrome(l) >= first) 
and (end_of_paiindrome(1) <= last)) then 
begin 
end of „palindrome( i):=0; 
comment flag smaller pallndrome; 
end; 
end; 
end; comment All previously recorded palindromes 
compared wlth last input; 
if entry = true then 
begin 


comment larger than ail previous or overlapplnug or disjoint; 


begin—of—palindrome( jx) :=first; 
end_-of_paiindrome( Jx) := last; 
Jx:i=yx+!l; 
end; 

end record_palindrome; 


comme n t main; 

initialize; 

read. and „write input cards; 
palindrome check; 

if jx=1 theu text3 


else write. all palindromes; 
end. 


FIGURE 1 
Page 4 of 4 
PROGRAM LISTING 


42 








3. Program Graphs 

Figure 2 nresents the control flow directed graph repre- 
sentations of the significant procedures of the example progran. 
The graphs, originally presented in Reference 20, are annotated 
w1th key-words indicating the structured programming constructs 
comprising the decision nodes, lower-case letters which label 
the arcs, upper-case letters representing the counters placed on 
the individual decision-to-decision paths for path analysis, and 
"with complexity measures of the procedures. The complexity 
measures shown are defined as follows: 

a. The number of statements is a count of the source 
code statements in the procedure. 

b. The number of nodes is a count of the nodes in the 
control flow graph. Nodes are points of starting, Stopping, 
branching, or merging of control flow; i.e., decision points. 

c. The number of arcs is a count of the arcs in the 
graph. Arcs are concatenations of zero or more program state- 
ments with no decisions except at the nodes. 

d. The cyclomatic number of a strongly connected graph 
1s equal to the maximum number of linearly independent circuits 
(27). A program control flow graph with one entry and one exit 
such that each node can be reached from the entry and such that 
the exit can be reached from every node can be considered as a 
| strongly connected graph with an imaginary arc from the exit 
| node back to the entry node. For such a control flow graph the 
Mejélomatile number can be variously interpreted as the maximum 


number of independent paths, one more than the number of predicate 


43 











nodes (nodes with more than one path leaving), the number of 
regions in the graph (plane graph with no arcs crossing), or 
the number of arcs minus the number of nodes plus two (27). 
The experimental method described in Section E of this chapter 


makes use of the cyclomatic number. 
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Procedure: 
INITIALIZE 
Number of statements: 1 
Number of nodes: 
Number of arcs: 
Cyclomatic number: 
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Procedure: 
READ AND WRITE 
INPUT CARDS 


Number of statements: 


Number of nodes: 
Number of arcs: 
Cyclomatic Number: 
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Procedure: 
PALINDROME CHECK 


Number of statements: 


Number of nodes: 
Number of arcs: 
Cyclomatic number: 
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Procedure: 

CONTINUE -CHECKING 
Number of statements: I 
Number of nodes: 

Number of arcs: 
Cyclomatic number: 
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Procedure: 


RECORD* PALINDROME 
Number of statements: 21 
Number of nodes: 10 
Number of arcs: 13 
Cyclomatic number: 5 
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Procedure: 

MAIN 
Number of statements: 6 
Number of nodes: 6 
Number of arcs: 6 
Cyclomatic number: 2 
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4. Error Data 
Forty-four errors were detected during original program 
development. Error descriptions by type are recorded in Reference 
20. Table I presents the errors (using Hoffman's original error 
mumbering) which could be directly related to a particular pro- 


gram fragment. 


TABLE I 


SELECTED ERRORS 


Error 
Number Procedure Description 
l read+and+write... Need for 256-character variable 
"text" in addition to an 80- 
character buffer noted. 
3 initialize Syntax error. 
4 initialize Syntax error. 
33 palindrome+check Error Iinzimıts to Counter ot 
for statement. 
36 : palindrome+check Missing "if ix4-2" resulted in 
indexing error at run. 
57 inıtialize "jx" not initialized; resulted 
in indexing error. 
42 initialize VIX" inte talizea to 0. vice l. 
5, Intuitive Test Cases 


After a first examination of the example program and 
before commencing any of the verification experiments, a set of 
test cases was selected by intuition which appeared to test the 
program's handling of all conditions significant to proper 
program operation. Those test cases are listed in Table II. 
The intuitive test cases were used for conducting additional 
dynamic testing after completion of the experiments using the 


methods described in the remainder of this chapter. 
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TABLE II 


INTUITIVE TEST CASES 


Test String A String or 
Number Length Mas String Description 
1 2 "xx'' - length 2 palindrome 
2 3 "xyz" - length 3 palindrome 
3 l Invalid string length 
4 29 Invalid string length 
5 256 A maximum length string containing palin- 


dromes of length 10, 9, 6, and 12, of 
which the first included length 3 palin- 
dromes at both ends, the second and third 
overlapped, and the fourth was written 
across an input card boundary. 


6 15 String with no palindromes 
7 100 Entire string one palindrome 
8 256 One maximum length palindrome 


Ba PROOF OF CORRECTNESS 

A method of formal proof of correctness was used to verify 
the logical correctness of the algorithm of the example program. 
The method required the assumption that the environment in which 
the program operates is also logically correct, most particularly 
that the compiler and operating system ensure performance -of the 
expected semantic actions for the program statements. 

References 9,15,19,25 and 26 were consulted to develop the 
methodology for constructing the proof. The work of Floyd (15) 
1s considered the basis for mathematical program proofs; the 
paper by Manna and Waldinger (26) was particularly helpful in an 
operational sense, and Hoare's paper (19) was applicable to the 
treatment of procedure calls. 

The first step in constructing the proof was to formalize 
the required result of the program in a logical statement called 


the output assertion, and to describe the restrictions on input 
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data as an input assertion. Translating the rather loosely 
defined purpose of finding palindromes to an output assertion 
required significant analysis of the requirements. 

The proof itself was constructed using the method of in- 
variant assertions to show partial correctness; i,e., that when the 
input data satisfied the input assertion, the output assertion 
was satisfied if the program terminated. Termination of the 
program was proven separately by Edie for each loop a set 
and an ordering relation on that set such that the set can have 
no infinite decreasing sequences (well-founded ordering), and 
defining a termination expression which is a member of that 
set and which is decreased each time control passes through the 
loop. The proofs of partial correctness and termination together 
establish the "total correctness" (26) of the program. 

The method of invariant assertion involved inserting appro- 
priate intermediate assertions (also called Floyd assertions) at 
selected labels in the program such that they defined a condition 
which would be logically true each time control passed through 
that label (hence the name invariant). At least one intermediate 
assertion was inserted on every loop. Corresponding to each 
path between assertions a verification Cond tion was written. A 
verification condition is a theorem of the form <assertion 1> 
and <semantic meaning of program statements on path > implies 

< assertion 2>. Proving all verification conditions completed 
the proof of partial correctness. 

The construction of appropriate verification conditions was 


aided by using the invariant deductive system described in 
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Reference 26. The notation {P} F {Q}, where P and Q are logical 
statements (assertions) and F is a program fragment, is used to 
mean that if P holds before executing F and if F terminates, 
then Q holds after executing F. Thus the proof of program correct- 
mess is a proof of the invariant statement: 

{input assertion} program (output assertion). 
Rules of inference were supplied in Reference 26 to provide sub- 
goals for proving certain invariant statements; in particular 
there is one rule of inference for each statement type in the 
programming language. For instance, the rule for conditional 


statement "IE R then F else G" is written as: 


(P and R} F (QJ, (P and aR} G {Q} 
(P) if R then F else G {Q} 

The notation signifies that proof of the two invariant statements 
in the nominator of the "fraction" is sufficient to infer the 
invariant statement in the denominator. 

The reference provided rules of inference for assignment 
statements, conditional statements, while statements, and for 
the concatenation of statements. Additional rules were formu- 
Htedifor iterative tor statements and procedure calls. The 
rules are introduced as required in the presentation of the 


proof (Appendix A). 


C. DISTRIBUTED CORRECTNESS 
Test cases for dynamic testing were selected using a criterion 
, based on the condition table method of Goodenough and Gerhart 


(17) and the principle of distributed correctness described by 


54 





Geller (14). The criterion was not proven reliable and valid, 
but an effort was made to show that the data selected were 
representative of equivalence classes covering the input domain 
of the program such that correct operation for all data in the 
domain could be induced from correct operation for the test data. 
As in the proof of correctness, input and output assertions 
were stated. At selected labels in the program (fewer than in 
the correctness proof), "synthesized assertions" (14) were in- 
serted, similar to Floyd assertions but more general. The syn- 
thesized assertions expressed invariant conditions of the program. 
A condition table was constructed (if necessary) to analyze all 
conditions affecting program operation from the previous asser- 
tion to the one under consideration. Test data were selected 
for each class identified in the table (similar to the decision 
rules of a limited-entry decision table), and a "test data 
assertion' was stated, namely that execution of the program 
fragment with the test data would satisfy the synthesized 
assertion. The test data assertion was verified by dynamic 
testing. At the same label, a generalization assertion was made 
attempting to state the conditions for correct operation of the 
program fragment, and where possible the synthesized assertion 
was proven from the test data and generalization assertions. In 
several cases, however, a basis for verifying the generalization 
assertion could not be found and hence the verification method 
could not be claimed to have proved program correctness through 
testing. Certainly, however, an intuitive feeling of "high" 


reliability and validity of the test case selection criterion 


55 





ae peli - 


was established. 
The principle of distributed correctness was called upon to 
infer program correctness from the correct operation of the 


distributed program fragments verified by the synthesized 


assertions. 


D. PATH ANALYSIS 
ii baste technique 

Path analysis techniques are described in References 21, 
22, 23, 31 and 32. For the example program, test data were 
selected to force program traversal of each arc of the program 
control flow graph. Execution of the arcs labeled with upper- 
case letters on the graphs of Figure 2 is sufficient to ensure 
traversal of all arcs. Data were selected to satısfy path pre- 
dicates for each such arc, predicates which describe constraints 
on the inputs to ensure execution of the arc. The program was 
instrumented with a counter on each labeled arc to count the 
number of arc traversals, thus ensuring after testing that no 
arcs had been missed. 

More stringent criteria could have been applied, but execution 
of all possible control paths was not possible since the program 
has an infinite number of paths. 

2. W Extended Technrgue 

The method of selecting test data as described above 


was repeated with the additional criterion that each conditional 


| branching statement with more than one predicate be executed 


with each possible combination of truth values of the predicates, 


56 





thus expanding the class of errors that might be detected by 
the tests. Additional path predicates were considered and a 


larger set of test data was selected. 


E. INDEPENDENT SUB-STRUCTURES . 

A method for selecting test cases which is similar to path 
analysis has been suggested in References 27 and 33. As applied 
herein, the technique was to decompose the control flow graph 
of each procedure of a program into independent circuits corre- 
sponding to language constructs and to use these sub-structures 
as an aid in identifying control flow paths for testing. The 
cyclomatic number of a single-entry single-exit procedure is 
the maximum number of such sub-structures; these independent 
circuits can be identified by inspection for simple graphs or 
more generally as follows: 

A spanning tree (33) is a connected sub-graph consisting of 
all nodes of a procedure's graph but containing no circuits. Its 
arcs are called branches. There is one independent circuit 
corresponding to each arc of the parent graph not included in 
the spanning tree; these arcs, including an imaginary arc from 
the exit node back to the entry node, are called chords. As 
each chord is added to the spanning tree, the corresponding in- 
dependent circuit can be identified. 

A matrix representation of the circuits was useful in gener- 
ating control paths for dynamic testing from the sub-structures. 
A fundamental circuit matrix (33) was constructed with rows 


corresponding to arcs (chords and branches); its entries were 
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0 for arcs not contained in a circuit, 1 for arcs oriented in 
the direction of an assumed circuit flow, and -1 for arcs 
oriented against the assumed flow. Chords were listed on the 
left of each row, forming a unit matrix because there is a one- 
to-one correspondence between chords and circuits. 

The usefulness of the fundamental circuit matrix was that 
linear combinations of circuits (the rows) having at least one 
arc in common generated control paths useful for testing. Selec- 
tion of paths in this manner satisfied a criterion more stringent 
than traversal of each arc at least once, while considerably less 
stringent than traversal of all possible paths. 

In Section E of Chapter IV, the results of the application 
of this technique are discussed. Following the generation of 
the paths to be tested, test data were selected to satisfy the 


path predicates and dynamic testing was conducted. 
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IV. ERRESENTATEONZOE RESULTES 


A. STATIC ANALYSIS 

Prior to the commencement of the experimental methods, 1.0 
man-hours of effort were expended in static analysis of the 
example program. Code was read to check syntax and reachability 
of program fragments, and control flow graphs were examined to 
check for adherence to structured programming constructs and 
to learn the general flow of the program. No exceptions were 
moted in these areas. 

All global and local variables were examined to ensure 
proper declarations and to check the transitions among the states 
of being undefined, defined and not referenced, defined and 
referenced, and an anomalous state (23). No illegal state 
transitions were found; however, two instances of questionable 
programming practice were noted. First, the string array variable 
"cardbuffer" is initialized to contain 80 blank characters in 
the procedure "initialize" (state = defined and not referenced). 
In a data flow sense, the next action performed on that variable 
sta re-derine ıt in the procedure read+and-= writes input*cards,” 
thus transitioning to the anomalous state. Since the variable 
is re-defined before being referenced, the initializing of 
Bcardbufter" in the "initialize" procedure is superfluous. 
second, all iterative counters In for statements in the example 
program are explicitly declared. Because the Algol-W compiler 
implicitly declares such counters, the effect in the example 


program is to explicitly declare several variables that are 
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subsequently not defined or referenced. Although this is a 
shortcoming in style, the superfluous declarations cause no 
111 effects other than to waste a small amount of storage. 

The verifications performed during static analysis were 
required to ensure satisfaction of several assumptions for the 
experiments in correctness demonstration, particularly that the 
program has no significant data flow anomalies and that the 
program is well structured and procedures do not contain 
Statements leading to unexpected side effects. The two in- 
Stances of style noted above were not corrected prior to ex- 


perimentation. 


B. PROOF OF CORRECTNESS 

The detailed proof of correctness for the example program 
is presented in Appendix A. The first step in constructing 
the proof was to formalize the output specification of ‘the 
program, a task requiring 0.8 man-hours of effort. It was 
desired to prove that at program termination the arrays 'begin- 
of+palindrome" and "end-of-palindrome" would contain, correspon- 
ding to indices starting from l, integers representing the 
beginning and ending characters in the string "text" for all 
palindromes in the string, subject to the constraint that 
palindromes fully contained within a larger palindrome would 
not be recorded. A palindrome initially recorded in the arrays 
and subsequently found to be included in a larger one would be 
"deleted" by setting the "end-of-palindrome" entry to zero. 


Overlapping palindromes would be recorded. 
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The formal statements made for the specification are ("g" 
is an abbreviation for "length+of<+text"; "bop" and "eop" are 
abbreviations for the beginning and ending entry arrays; "jx" 
is a counter which is equal to one more than the number of entries 
made in those arrays): 

EO: Y x[(2<=x<=2 A textí(x-1)=textí(x))=> 

dy (y<jx a 1<=bop(y)<=x-1 ^ x<=eop(y)<=2)] 
R: Yx[(3<=x<=2 A Pee Ste e 

dy (y<jx A 1<=bop(y)<=x-2 A x<=eop(y) <=2) ] 
ES Wy[(0<y<jx A bop(y)>1 A O<eop(y)<2) => 

(text(bop O =1]Stextisop (y) +10] 

D: Wy | (0<y<jx A =(eop(y)=0)) => 

[string (bop(y) ,eop(y))=ok A bop(y)>=l1 A eoply)<=2 

AVZ( (ecc TUN AER 

( — (bop(z)=bop(y)) 


A (bop(z)<bop(y) => eop(z)<eop(y))) )] 


The assertions Q and R require, respectively, that all 
palindromes of length 2 and length 3 are included within some 
entry in the arrays “bop" and "eop." Due to the symmetry of 
palindromes, all must contrain a palindrome of length 2 or 3 at 
the center; therefore, when conditions Q and R are satisfied, 
all palindromes have at least been detected by the workings of 
the algorithm, even if their total extent has not been recog- 
nized. Condition S requires that any valid entry in the arrays 
"bop" and "eop" represents as long a palindrome as can be 
recognized starting from the length 2 or 3 palindrome at the 


center; symmetry is again relied upon. Finally, condition T 
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requires that all strings represented by valid entries (those 

with non-zero "eop'' entry) are in fact palindromes (the notation 
"string(1,2)=0k" is used to indicate that the sub-string starting 
at position 1 in "text" and ending at position 2 is a palindrome), 
and that no entry in the arrays "bop" and "eop" is included 

with another entry. 

Together the four assertions provided a formal statement 
that could be proved from the semantics of program statements 
and the assumption that the input constraints (see Appendix A) 
have been satisfied. 

Given the output specification to be proven, five procedures 
were determined during static analysis to have no bearing on the 
program's performance of the desired process. Procedures "textl," 
"text2," and "text5," merely print output labels; "blank+lines" 
inserts blank lines in the output. Procedure 'write-all-palin- 
dromes," while complex, serves only to print the strings corre- 
sponding to the entries in the previously mentioned arrays. No 
correctness proof other than for termination was supplied for 
these procedures. 

For the remaining significant procedures, Table III presents 
the man~hours of effort expended in constructing their proofs. 

As is discussed in Chapter V, there was a relationship between 
procedure complexity and the time to construct a proof for the 
procedure. The time required to prove procedure "read*-and*write- 
input+cards,' the first somewhat complex procedure proved, was 


distorted by the presence of a significant learning curve. 
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TABLE III 


TIMES TO CONSTRUCT PROOFS 


Task Accomplished or 
Procedure Proved Man-Hours 


Formalize output specification 
"anitialize” 

Show termination of 5 utilities 
"read+and+write+input+«cards" 
"palindrome-check" 
"continue+checking" 
"record+palindrome" 

"ma an” 


O UE F R OO © 
e. e e e * o . e 
NM U1 CO DN) O^ CO O 





Total DS: 


Gl 
e 
U 


E. DISTRIBUTED CORRECTNESS 

The detailed demonstration of correctness of the example 
program using the condition table method and the principle of 
distributed correctness (described in Chapter III) is presented 
in Appendix B, As in the formal proof of correctness, this 
method required formalization of the output specification as 
a first step; the same output assertions were established as 
in the formal proof. The six significant procedures were tested 
by choosing synthetic assertions, test data assertions, and 
generalization assertions, and then executing test data to 
verify the assertions. Table IV presents the man-hours of 


effort expended in demonstrating correctness by this method. 
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TABLE IV 


TIMES TO DEMONSTRATE CORRECTNESS 


Task Accomplished or 
Procedure Shown . Man-Hours 


Formalize output specification 
"initialize" 
"read+and+write+input+cards 
"palindrome+check" 
"continue+checking" 
"record+palindrome" 

"main" 


OW OOOO 
PNW WO NND 00 


SI 
un 


Total 


The test data elements used to verify the test data asser- 
tions in the correctness demonstration are consolidated in 
Table V into one comprehensive set of test cases; the palindromes 
which should be recorded for the given texts are indicated by 
underscoring. The degree to which these test cases satisfied 


the requirements for an ideal test is discussed in a later section. 


TABLE V 


TESISCASES TBENTIELEN BY 
CONDITION TABLE METHOD 


Test Length Test Length 
Number of text Text Number of text Text 
1 2 ab 15 4 aabc 
2 2 aa 14 4 abba 
3 80 Note 1 15 4 abbc 
4 81 Note 1 16 5 abbad 
5 160 Note 1 17 5 abbcd 
6 240 Note 1 18 5 abccb 
7 250 Note 1 19 5 abccd 
8 3 aba 20 6 abceba 
9 3 aab 21 6 abcc 
10 3 abb 22 6 abccde 
11 4 abcc 23 9 baaabaaab 
12 4 aaaa 
Note 1 - any text which includes overlapping palindromes 
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For purposes of comparison with later sets of test cases, 
it is noted that execution of the above tests required 0.88 


seconds of CPU time. 


D. PATH ANALYSIS 

l. Basic Technique 

Static analysis of the program identified 21 individual 

decision-to-decision paths in the program control flow graph. 
The program was instrumented with integer counters placed in 
added assignment statements to record the number of traversals 
of each of these arcs (which are identified by upper-case letters 
in Figure 2, Chapter III). The analysis.and instrumentation 
required 0.8 man-hours of effort. 

Path predicates were established and test cases selected to 
force traversal of each arc at least once (0.3 man-hours required). 
For the example program the path predicates were quite simple 
to satisfy. Finally, the test data (shown in Table VI) were 
used in dynamic testing of the program (0.2 man-hours). Table 
VII lists the individual arcs and the number of traversals of 
each which were recorded. No program errors were detected. Each 
arc was traversed at least once, and thus the selected data 
provided at least a "minimally thorough" test of the program 
(22). The total effort involved in the application of this 
method was 1.3 man-hours. The tests required 0.05 seconds of 


CPU time. 


65 





TABLE VI 
TEST CASES IDENTIFIED 


BY PATH ANALYSIS 


Test Length 
Number of text Text 
1 l -- 
2 2 Xy 
| > 7 baaaaca 
TABLE VII 


ARC TRAVERSALS USING 


PATH ANALYSIS DATA 


-ee | | mm ib eee ee _ — See 


Test 2 101922777 1 d: l 
Test 3 _117113332115632433_1 
Total j n 


2. Extended Technique 


Preceding the arcs labeled D, N, P and Q in Figure 2 
are decision statements involving two or more predicates (e.g., 
me (A and B) then"). The basic path analysis technique pro- 
vided simply for traversal of each arc following such decisions 
(i.e., "A and B" true, and "A and B" false). A more thorough 
test of a bi-conditional decision would execute the decision 
Bstatement under the four truth combinations for the two predi-- 
cates (A true and B false, A true and B true, A false and B 
true, A false and B false); similarly a tri-conditional decision 


could be executed under the eight truth combinations for the 
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three predicates. 
Analysis of the appropriate path predicates identified 
four additional test cases (Table VIII) which, when added to 
the three cases selected by the basic technique, ensure execution 
of multi-condition decision statements under all (possible) 
combinations of truth values for the decision predicates. Table 
IX presents the arc traversals recorded for the additional tests. 
No program errors were detected. The total additional 
effort to select the additional cases was 0.9 man-hours; 
therefore, the total time to apply the extended path analysis 
method was 2.2 hours. The additional tests required 0.18 
seconds of CPU time, for a total CPU time of 0.23 seconds for 


the extended method. 


TABLE VITI 
TESTA CASES IDENTIFIED BY 


EXTENDED PATH ANALYSIS 


Test Length 
Number of Text Text 
4 257 -- 
5 J aaa 
6 5 baaab 
7 160 * 


*Any string of 160 


characters 
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TABLE IX 
ARC TRAVERSALS USING 


EXTENDED PATH ANALYSIS DATA 


] Are. 2 A B E D E E G H J 


Test 4 1 

Test 5 Zu: 1 3 1 | 2 1 
Test 6 1 i 5 1 1 Z 2 1 2 
Test 7 1 2 160 2 1 1 1538 153 
Total, 

Tests 1-7 2 5 6.177 6 5 8 164 5 102 


| Arc: KL MN P Q R S T U V 


Test 4 
Test 5 1 3 2 1 5 1 
Test 6 1 T 2 5 2 1 5 l 
Test 7 1 3 1 1 1 1 
Total, 
Tests 1-7: 5 5 85415 3 6 6 10 3 1 4 


E. INDEPENDENT SUB-STRUCTURES 


The techniques described in Chapter III, Section E, were 
applied to the six significant procedures of the example program 
to identify control paths for testing based on the independent 
language constructs of the procedures. A spanning tree (consis- 
ting of all nodes but containing no circuits) was constructed 
corresponding to each procedure control flow graph presented in 
Figure 2 (Chapter III); the arcs of the spanning tree were 
considered as branches. The remaining arcs of the parent graphs 
were considered to be chords, with a single independent circuit 


or language construct corresponding to each. The fundamental 
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matrices for the six procedures are presented below; the rows 
are labeled with the language construct names of the fundamental 
circuits; the columns are headed with the arc (branches and 
chords) labels, If a fundamental matrix has n rows, the first 

n column labels from the left are the chords and the remaining 
column labels are the branches. The matrix entries have the 


meanings described earlier. 


Procedure "initialize": 


Ee HDC ed 
1 0 1 1 1 0 main-line 
0 1 0-1 0 1 if-then 


h d f a b c e g 

LU 0459 07949 1 main- Line 
0 1 0 0 0 1 0 0 while-do 
DEREN ZN TINTE OR 


Procedure "palindrome+check": 


E E MA A E AS IL LK 

1 0- 0 0 0 1. 1 0 0 0 8 0 0- 0 main- line 
0- 100000070. 110.8: 0-0 1¡£sthen 
00.1 0770070077070 =- 140771718- shién 
0 0 50 1 0-0 0 0-0 50-0 —D 1 -1  3fthen 
OO TTT OTE T Oa o 0030 O 
Procedure '"continue+checking": 

VIE DE AO AA 

L 0.01 0-0 0 0 Ll 1. main-Tinée 

0 1 0 0 0-1 1-1 0 0 if-then-else 

O AO A DA e do 
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Procedure "record+palindrome": 


Ud him a b c e fg j k 1 

1 0 0 0 0 1 0 0 0 0 0 1 1 0 main-line 

0 1 0 0 0 0 0 1-1 0-1 0 0 0 if-then-else 
emm o 1 0 0 0 0 0 0 1-1 0 0 O if-then 

Em 0 0. 1 O 0 1 0 1 0 1 0 0 0 for 

"O 0 0 1 0 0 0 0 0 0 0-1 1 if-then 
Procedure "main": 

pe a b c d f 

1 0 1 1 0 1 1 main-line 

0 1 0 -1 1 -1 0 if-then-else 


The control paths for testing were selected by using the rows 
(fundamental circuits) and all linear combinations of rows having 
one or more branches in common to identify sequences of arcs which 
should be tested. The paths for each procedure that were selected 
in this manner are presented below: paths are identified here in 


a node-to-node format (node numbers correspond to those in Figure 


2). 


Procedure "initialize': 
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Procedure "continue«checking": 


:2-7-8 
-2-3-4-6-2-7-8 
2035-66-27 «8 


HH HP 


Procedure 'record+*palindrome": 


Procedure "main": 


1-2-3-5-6 
1-2-4-5-6 


Path predicates were established tor the control paths 
listed above and test cases were selected to force their 
traversal. The paths above followed by "*" have path predicates 
which cannot be satisfied by any input data; the given execution 
sequence is impossible for any allowable input. The minimal set 
of test cases selected to satisfy the path predicates is presented 
in Table X. Dynamic testing with these test cases revealed no 
program errors; 0.12 seconds of CPU time were required for the 
tests. Table XI describes the allocation of the 2.2 man-hours 


of effort expended in the application of this method. 
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TABLE X 
1E51 CASES TDENTEFTED BY 


INDEPENDENT SUB-STRUCTURES METHOD 


Test Length 
Number of text Text 
i: l -- 
2 2 xy 
5 2 aa 
4 5 aba 
5 3 abc 
6 7 " aabbbba 
TABLE XI 


TIMES TO APPLY METHOD OF 
INDEPENDENT SUBSTRUCTURES 


Task Accomplished or 
Procedure Shown Man-Hours 


"initialize" 
"read+and+write+1input+cards" 
"palindrome+check" 
"continter-cheexing" 
"record+palindrome" 

"main" 

Conduct dynamic tests 


ac 
DF aN AN F 


DI 
DI 


Total 


For purposes of comparison of the degree of arc coverage of 
tests conducted by this method with that of the path analysis 
tests, the instrumented version of the example program was 
executed with the test cases from Table X; the results are 


given in Table XII. 
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TABLE XII 
ARC TRAVERSALS USING 


INDEPENDENT SUB-STRUCTURES DATA 


ce eee eee eee a a - -ep s M. 2 0- 


Test 1 L 

Test 2 LA el 1 l 1 

Test 3 IER DI RT 1 l E 1 

Test 4 Z T 1 I 1 1 

Test 5 Ko 2 L l 

Test 6 VALS AL EAS LIS 1 
Total SS S05 37000030 2000430 LIE 22779 


Ey. INTUITIVE TESTS 

The intuitive test data selected prior to conduct of the 
previous experimental demonstrations of correctness were used 
for dynamic testing. No program errors were revealed. For 
purposes of comparison of the degree of coverage with other 
methods, Table XIII presents the results of execution of the 
instrumented program with the intuitive test data listed in 


Table II (Chapter III, Section A). The selection and testing 


| of these data required 0.7 man-hours of effort; the tests 





| consumed 0.44 seconds of CPU time.. 


| 
| 
f 


1.3 





TABLE XIII 
ARC TRAVERSALS USING 


INTUITIVE DATA 


re B EE GA 


| Test 1 1 i 2 1 J 1 

| Test 2 T 2S 
Test 3 1 
Test 4 1 
Test 5 1 4 256 4 1 20207 DOLO 
Test 6 D 1 15 1 d 14 15 
Test 7 1 2 100 2 ] 1 98 98 
Test 8 1 4 256 4 1 17254 254 
Oba; 
Tests 1-8 2 6 15 632 15 6 6 620 4 616 


Test 1 1 1 1 ] 
Test 2 1 I. 1 1 
Test 3 
Test 4 
Test 5 I l4 6 6 1 12910 5 1 1 
Test 6 a I 
Test 7 1 49 1 1 1 
Test 8 I 127 1 1 I 
| O EA E ey 
| Total. 
Tests 1-8 6 190 6 10 1 1 -T0 9 1 1 5 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. COMPARISON OF METHODS 


1. Level of Effort 

Table XIV is a summary of the man-hours of effort required 
f for each method of demonstrating the correctness of the example 
ran. broken down by procedure for those methods where pro- 
cedures were examined individually. The cyclomatic number and 
number of statements for each procedure are included in the table 
as measures of procedure complexity. The times to apply the 
verification techniques are to be compared with one another and 
with original program development times of 5.0 hours to design, 
7,0 hours to code, 4.0 hours to debug, and 5.8 hours to test (21.3 


hours total). 
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TABLE XIV 
SUMMARY OF TIMES 


TO DEMONSTRATE CORRECTNESS 


Cyclomatic Time (Man-Hours) Per 
Task or Number and Method 
Procedure Nom OE otmts AA NU. m EN: 
Formalize output 
Specification m 04320058 - - - - 
winitialize" 2 el W302 -- ~ DT 
Show termination 
of utilities - 0.6 - - - - 
"read-and-write..." So IS La UE - - 0.2 
"palindrome-check'" S E 1.6 0,9 - - 0% 6 
"continue-checking" STONES IMS I. - - D 
"record+palindrome" STI 285752 - - 0.7 
"main" 222.228 02005 - - - Del 
Conduct dynamic 
testing - - j - - 092 
Total 1555 us] 2222 
Methods: 
A - Formal proof 
B - Condition table/distributed correctness 
C - Basic path analysis 
D - Extended path analysis 
E - Independent sub-structures 
* 


- Test time included in times for procedures. 


Quite expectedly the two more formalized verification tech- 
niques (proof and condition table method) required considerably 
more effort than any of the other methods, and in fact required 
more hours of effort than were involved in program design (time 
to construct the proof exceeded even the time to design and code). 
As the subsequent discussion of the thoroughness of each method 


indicates, these two methods provide higher confidence in program 


76 





correctness than the other simpler and more mechanical methods. 

The question becomes whether the increased return from formal 
methodology is worth the cost. The complexity and importance of 
the software, budget constraints, and several other factors come 

to bear on the decision, and the decision should be made separately 
for each software project. 

From a philosophical standpoint at least, ex post facto 
proof of correctness is inefficient because of a great deal of 
duplication of effort. The logical process of constructing the 
proof, in the case of this experiment and in general, requires 
at least as thorough an understanding of the application and of 
the program control structure and data flow as does the design 
and implementation effort. The logical techniques of proof can 
give excellent evidence as to the correctness of programs (but 
not conclusive; see Ref. 15 and others) and are clearly desirable 
for use, but a higher cost effectiveness than that suggested from 
this experiment is required. Possibilities include attempts to 
automate ex post facto proving of correctness or to introduce the 
lgocal techniques in the design and implementation of software. 
These alternatives are major areas of research; brief mention 
is made here. 

Structured programming concepts, advanced language design, 
and formal definition of requirements are examples of software 
engineering efforts to emphasize the use of logical methods in 
the design and implementation of provable programs. Mann has 
discussed the feasibility of using logic techniques to generate 


programs guaranteed to satisfy the output specifications, thus 
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obviating the need for ex post facto verification (26). It is 
in this area that the greatest promise for correct software is 
to be found. 
Several aspects of the formal proof process may be subject 

to automation. Manna discussed briefly in Reference 26 (pp. 203- 
204) progress that has been made in systems to automatically 
generate invariant assertions and verification conditions and 
systems (theorem provers) to prove the verification conditions. 
Both tasks are formidable and it is unlikely that full automation 
can be achieved; yet, partial solutions would be extremely help- 
ful in reducing the tedium involved in the process of formal 
proof. The limitations on automation of the process are succinctly 
stated by Dijkstra (9): 

The distorting spell of speed still seems to 

take its victims. We see automatic theorem 

provers proving toy theorems, we see automatic 

program verifiers verifying toy programs and 

one observes the honest expectation that with 

faster machines with lots of concurrent processing, 

the life-size problems will come within reach as 

well. But, honest as these expectations may be, 

are they justified? I sometimes wonder... 

The level of effort required to apply the condition table 

method of selecting test data in a fashion as nearly reliable 
and valid as possible (according to the theory of testing dis- 
cussed in Chapter II) compares more favorably with the original 
program design effort. If similar relationships exist for large- 
scale applications, the method is likely to be effective at 
reducing the life cycle cost of software as the method appeared 


in these experiments to offer a greater ability to locate errors 


than less formal methods, thus reducing maintenance costs. 
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Evidence of the cost effectiveness of this or similar formalized 
test case selection criteria is required from large-scale appli- 
cations in a commercial environment to be conclusive. 

It is interesting to relate the effort required to apply 
to individual procedures the methods A, B, and E (Table XIV) with 
the complexity measures of these procedures. While the sample 
size of the data collected here is too small for statistical 
significance and the data are distorted by the presence of learning 
curves (e.g., procedure "read+and+write+input+cards" was the 
first procedure with loops proven correct, and several false 
starts were included in the 4.2 hours of effort), there did appear 
to be a relationship between complexity and effort to demonstrate 
correctness. Although the level of effort did not linearly 
relate to the magnitude of either of the measures of complexity 
shown in Table XIV, effort appeared to increase with increasing 
complexity, and the cyclomatic number appeared to be a better 


predictor of effort than did the number of statements. 


2. Thoroughness of Verification 
As discussed in Section B of Chapter II, the requirement 

for an ideal test according to the theory of testing presented 

in that chapter may be satisfied in several ways. Selecting no 
test data and proving that the program is correct (i.e., contains 
no errors) clearly satisfies the criteria for an ideal test. 
Accordingly, on the basis of the proof of correctness constructed 
as part of this experiment it can be stated that the example 


program is correct as written, provided the proof contains no 
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errors and no unwarranted assumptions. That proviso is not easily 
ignored; Reference 15 is only one source of examples of programs 
"proven" correct which in fact contain errors. Nonetheless, the 
proof provides a high degree of confidence in the correctness of 
the example program. 

The several path analysis strategies, including the identi- 
fication of paths for testing by decomposition into independent 
sub-structures, did not include any attempt to show the reliability 
and validity of the test cases selected. Consideration of possible 
errors in the program, particularly in the statements controlling 
control flow, revealed several potential errors that would be 
detected using the test cases of the extended path analysis tech- 
nigue (multi-conditions emphasized) but not by one or both of 
the other two path analysis methods, 


For example, if the statement 


while ((ix«-length-of-text) and 
(bufferposition«card limit) do 


in the procedure "read+and+write+inputecards" had the incorrect 
relational operator "bufferposition<=" vice "<", none of the test 
cases selected by the basic path analysis technique or by sub- 
structure analysis would reveal the error (no string sufficiently 
long), but test 7 (length 160) of the extended path analysis 
method would reveal the error through a run-time indexing error 
on assigning the 8lst character to "text." Similarly, if in 


procedure "record+palindrome" the statement 


if ((first>=begin+of+palindrome(i)) and 
(last<=end+of+palindrome(i))) then 
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omitted the "or equal" test from the ">=" and "<=" operators, 

the basic and extended path analysis test case 3 ('baaaaca") 

would reveal the error by recording three palindromes (baaaaca, 
baaaaca, and baaaaca) which are included in the larger palindrome 
(baaaaca) and should be ignored. The error would not be revealed 
by the test data selected from independent circuit considerations. 

Because there exist potential errors that would not be 
revealed by the path analysis test sets (including the extended 
method set, as will be shown in the next paragraph), the criteria 
as applied in these experiments were not valid and reliable in 
the meaning of testing theory. While the particular errors 
revealed or not revealed in these experiments are peculiar to 
the program under test, selection of test data by any means of 
path analysis other than exhaustive path testing cannot be ex- 
pected to detect all program errors. 

The test cases selected by condition tables were capable of 
revealing all of the errors considered above, including the two 
specific errors mentioned (test cases 4, 5, 6 and 7 for the 
first, test 23 for the second). Additionally, there were po- 
tential errors which could be detected through dynamic testing 
only by the test cases selected by this method. These results 
are peculiar to the specific program under test but are consid- 
ered representative of the capabilities of the several methods. 
(It is not suggested that the condition table method is in 
general capable of revealing all errors.) 


For example, if in procedure "continue-checking" the 


31 





statement 


while ((first>1) and (last<length+of+text) 
and (palindrome=true)) do 


mistakenly on tamned Wlast<=" vice "lasts," test case 5 ("baaaaca') 
of the path analysis techniques and test 6 ("aabbbba") of the in- 
dependent circuit method would both erroneously cause traversal 
of the arc '"M" (see Figure 2; arc.'"M'" sets palindrome" equal to 
the value "false") during the calls to the procedure with string 
(first,last) being the underscored palindrome, but there would 
be no external effect noticeable to the tester and the error 
(which has potential to cause an indexing error) would go unde- 
tected. However, the condition table for assertion B17-18 (para- 
graph E.1. of Appendix B) would cause the error to be noticed when 
examining the predicates of the assertion as required by the method 
during execution of test element "abb." 

thas lócalization of test effort A by using the prin- 
ciple of distributed correctness is one of the most powerful 
aspects of the method as used in this experiment. While the 
localization added to the effort required (full knowledge of the 
program's internal structure was required), it was the localization 
of analysis that enabled some positive statements to be made re- 
garding the validity and reliability of the selected test data. 
While in several cases it was not possible to prove the generali- 
Zation assertion for the selected test data assertion, in each 
case a high degree of confidence was established that the test 
data did in fact partition the input domain for the program frag- 
ment under consideration into equivalence classes with respect 


to program operation. 
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From this confidence and the. fact that no input data were 
excluded from selection, it was concluded that the criterion 
for selecting test data as applied to this program was valid 
and "almost reliable." Additional work in identifying theorems 
which can be used in generalizing from specific test data to 
the entire input domain is needed and offers an opportunity for 
a highly reliable testing methodology. 

The error data provided in Table I, from the original program 
development process, was not useful for discriminating among 
the methods applied in verifying the program. Each method 
would detect the presence of the errors described in Table I. 

It is interesting that the set of intuitive test data (Table 
II) selected prior to thorough analysis of the example program 
is capable of revealing all of the errors considered, including 
the "last«-" vice "last«" error in "continue-checking" (a run- 
time indexing error would occur for "text(last-1)" for test case 
8 as a result of that error). However, the method of casual 
or intuitive selection of test data is not in any way desirable; 
the error detection capability in this case is due only to luck 
and the relative simplicity of the program function, and the 
cost-effectiveness penalty in terms of CPU time expended on 


test cases which are in fact not distinguishable can be severe, 


B. SUMMARY OF CONCLUSIONS AND RECOMMENDATIONS 
This section presents a summary of the conclusions drawn in 


the main text of this thesis. 
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l. The need exists for greater relative emphasis on design 
and implementation techniques as compared to verification tech- 
niques (pages 13 and 77-78). 

2. Significant efforts are required in applying the disci- 
pline of software engineering toward refinement or replacement 
of the verification methods now in use (page 14). 

3. The formal proof of correctness and the application of 
the condition table method based on distributed correctness 
required significantly more effort than the path analysis stra- 
tegies (page 76). 

4. There are serious limitations on the feasibility of auto- 
mating the process of formally proving program correctness (page 
286). | 

5. There was some positive correlation of the level of 
effort required to demonstrate correctness with the complexity 
of procedures as represented by the cyclomatic number (page. 79). 

6. The proof of correctness of the example program provides 
a high degree of confidence in the correctness of the program 
(page 80). 

7. The path analysis strategies as applied in these experi- 
ments did not provide reliable and valid criteria for selecting 
test cases. Selection of test data by any means of path analysis 
other than exhaustive path testing cannot be expected to detect 
all program errors (page 81). 

8. The condition table method using the principle of dis- 
tributed correctness afforded a valid and "almost reliable" 


criterion for test case selection (page g3). 
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9. Additional work in identifying theorems which can be 
used in generalizing from specific test data to the entire 
input domain is needed and offers an nor en for a highly 
reliable testing methodology (page 83). 

10. Casual or intuitive selection of test data is not in 


any way desirable (page 83). 
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APPENDIX A 


FORMAL PROOF 


A. ASSUMPTIONS, ABBREVIATIONS, AND NOTATION 

Several assumptions about the example program were made in 
addition to those verified by static analysis and those mentioned 
in Section B of Chapter IV. It was assumed that the host environ- 
ment of the program (compiler and operating system) was error-- 
free. All input data read by the program were assumed type com- 
patible with variables - integers for integer variables, valid 
printable characters (including blanks) for string variables. It 
was assumed that the number of characters following the integer 
stating the length of the input character string was equal to 
that integer. The domain of the numerical values in all predi- 
cate formulaein the proof was assumed to be the integers only, 
and only interger division was intended; the operators div and 
meme were used to represent the integer quotient and remainder, 
respectively. 

Because several of the program variable names are verbose, 
the abbreviations listed below were used in the assertions and 


formulae of the proof: 


-2 length of text 

-2t cardlimit 

-eb cardbuffer 

-n number+of+input+cards 
=6 card+counter 

-bp bufferposition 

-bop begin+of+palindrome 
-eop end+of+palindrome 

-D palindrome 
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Figures 3 through 8, shown in the following pages, are 
listings of six program procedures with labeled invariant asser- 
tions inserted for purposes of the proof. Assertions AO and A58 
are the program input and output assertions.  Assertions are con- 
tained within braces "{ },' and in Figures 3 through 8 wherever 
successive labeled assertions follow a program statement, the 
intermediate assertion to be proved at that point is a conjunction 
of those assertions. Frequently assertions contain within the 
braces the names (labels) of earlier assertions; the meaning im- 
plied is a literal replacement of the label with its earlier 
expansion. In the terminology of Section B of Chapter III, the 
proof presented in this appendix is a proof of the invarient 
statement: 

{AO} program {A58 } 
This terminology and that for rules of inference (see the same 


section) are used throughout this appendix. 


B. ADDITIONAL RULES OF INFERENCE 
As mentioned in Chapter III, rules of inference similar to 
rose) in Reference 20 were formulated tor iterative tor státe- 
ments and procedure calls. Those rules are presented here: 
l. Iterative Rule 
The statement for C:=E step | until lL do F is logically 


equivalent to the program fragment: 





(P) // an assertion 
C:=E //C a counter, E an expression 
LIMIT:=L //L an expression 
{I} //an assertion 
more: if C>LIMIT then goto fini 
F //loop body 
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C:=C+1 
goto more 
Gini. 
{q} //an assertion 
Corresponding to this form of the statement, the rule of infer- 
ence is: 


P =I, (I A C<=LIMIT) F (I), I A C>LIMIT => 0 


(P) for statement (0) 


Z.. Gall Rule 

All procedures in the example program pass parameters by 
value, so that operations on the formal parameters within the 
procedure body do not affect the actual parameters. Global 
variables may however be modified in the procedures. The nota- 
tion p(f,g) represents a procedure p with some formal parameters 
f which operates on some global parameters g; the procedure has 
a body F and input and output assertions Q and R. A call to 
the procedure with actual parameters a is denoted by call p(a). 
S(a:=f) and T(a:=f) are the assertions in the calling program 
located before and after the call, with formal parameter names 
substituted- for actual. Tne rule of inference is: 

S(a:=f) => Q, R => T(a:=f), {Q} F (R) 
(S) call p(a) (TJ 


The rule is essentially a statement that a procedure call is 
proved when an in-line substitution of the procedure body is 
shown to be valid. In showing that R = > T(a:=f), the prover 
must verify that global variables referenced in T but not in 


R are not modified by execution of the procedure body. 
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B- PROCEDURES TEXT!,2,5 

Because these procedures do not contribute to the essential 
program performance (as was determined during static analysis), 
only a superficial proof of correctness was performed. It was, 
however, necessary to show termination in order to verify that 
program execution would not endlessly loop in one of these non- 
essential procedures. 

1. Input Assertion: {true} i.e., no restriction. 

2. Out AS on: (truej, 1,6., no restriction. 

3. Verification Condition: 

{true} procedure {true}, or true A null => true, where 
null is a notation for program statements having no significant 
effect. Proof of the verification condition is immediate. 

4. Termination 
The procedure has only one entry and one exit and con- 


tains no loops; therefore, it terminates. 


D. PROCEDURE BLANK+LINES; TERMINATION OF FOR STATEMENTS 
Similarly, only a superficial proof of this non-essential 
procedure was performed. 


1. Input Assertion:  1n>0) 
2. Output Assertion: {true} ; i.e., no restriction. 


3. Verification Condition: {n>0} procedure {true}. 
4. Proof 


Regardless of the value of the antecedent, the consequent 
remains the logical value true; therefore, the implication 


holds. 
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5. Termination 
Termination is assured if the error exit at the state- 
ment "assert(n>0)" is not taken, and if the for loop following 
terminates. The error exit is taken when n<=0. The input 
assertion guarantees n 0; therefore, the error exit is not taken. 

The for statement loop terminates whenever the value of the 
loop counter exceeds some pre-defined limit. Informally it is 
clear that, given a finite starting value and finite limit for 
the counter and given that the loop body itself terminates (as 
it does in this case - no nested loops) either the loop body is 
not executed at all (starting value exceeds limit) or eventually 
the counter must exceed the limit (since it is incremently by 1 
following each loop execution, by virtue of the 'step l'" portion 
of the statement, and no other assignments are made to the counter 
in the loop body), and the loop will terminate. 

More formally, let EXP=LIMIT+1-COUNTER be a termination 
expression, let N be the set of natural numbers, and let » be 
the usual greater-than relation. Note that N is well-ordered 
by ». In all implementations of a for statement or fne type 
described in the iterative rule of inference, if the initial 
value of EXP is zero or not contained in N (i.e., negative), 
then the loop body is not executed and termination is assured. 
Likewise, if the initial value of EXP>=1, the loop body is 
executed, COUNTER is incremented, and the subsequent value of 
EXP is (EXP-1)€ N. Since an infinite decreasing sequence of 
values of EXPEN is not possible (N is well ordered), the loop 


must terminate (EXP=0). 
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An important conclusion can be reached from the above proof 
of termination of the for statement in procedure "blank lines": 
every occurrence Of a statement of the type for C:=E step] until 


L do F terminates provided the program fragment F terminates. 


E. PROCEDURE WRITE+ALL+PALINDROMES 
As in the preceding cases, only a superficial proof was 
required for this non-essential procedure (non-essential in terms 


of the palindrome search problem). 


1. Input Assertion: (true): 
2. Output Assertion: (true). 


3. Verification Condition: 
{true} procedure {true}. The proof is immediate. 
4. Termination 
The procedure has only one entry and one exit. It con- 
tains no loops other than for statements (which have been shown 


to terminate); therefore the procedure terminates. 


Ree PROCEDURE INITIALIZE 

Figure 3 15 a listing of procedure “initialize” with the 
necessary assertions included. The notation "input(2)" refers 
to the data value in the input stream which will be assigned 


to the program variable "2", 


1. Input Assertion: Assertion Al. 


Ze QUEPut as se ntion: Assertion AZ. 
3. Verification Condition: {Al} procedure {A2}, 


Ho Proof. 


The proof of this verification condition follows directly 
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Al: 


procedure initialize; 


comment initialize all variables, read length_of_text, 
begin 

( 2<=1nput(1):=236 A ca=9 ) 

texti; 

Jx:=1; 


palindrome._counter:=1; 

cardlimit:=80; 

intfieldsize:=5; 

read( length. of. „text); 

if ((length. of. „text < 2) or (length. of „text > 256)) then 


begin 
write("lilegal input:”, 
" length of input. string ls: ",length_of.tex 
assert(false); 
end; 


had 


cardbuffer:=" 
C 2<=1<=256 A ca=8 A jx=1 A 1t780 A cb=blank ) 
end initialize; 


FIGURE 3 


PROCEDURE INITIALIZE 
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from the semantic meaning of the assignment statements and read 
statement. Each predicate of the output assertion is just an 
expression of an assignment made in the procedure body, except 
the term "'ca=0"', which is just a restatement of an input asser- 
tion predicate. The proof variable "ca" is discussed in the 
proof of the next procedure. A series of intermediate assertions 
could have been made, one following each assignment statement, 
to more formally indicate the method of proof. In particular, 
the 1f statement has been ignored in the preceding simple 
proof; it is discussed in the termination proof. 

Note that in Algol-W the meaning of an assignment of a 
single character value to a string of length greater than one 
1s to pad out the string variable on the right with blanks; thus 
the predicate "cb=blank", following the assignment statement 
"cardbuffer:=" ",'" means that "cb" initially contains 80 blanks 
("cb" is an abbreviation for "cardbuffer", a string array of 80 


characters). 


3. Termination 
The procedure is a concatenation of assignment statements, 

read Statement; a call to procedure "texti", and an ir State- 
ment containing a potential error exit (the assert statement). 
Because "textl" terminates, "initialize" will terminate at the 
output assertion provided the error exit is not taken. Since 
assertion Al ensures that 2<=4<=256, the compound statement 
forming the consequent of the if statement cannot be executed; 
thus the error exit cannot be taken, and the procedure does 


terminate. 
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G. PROCEDURE<READ<AND<WRITE+INPUT+CARDS 

Figure 4 contains the assertions for this procedure; several 
of the assertions use abbreviations listed earlier in this 
appendix. A proof variable "ca", a variable that is not an 
actual program variable, was used in this proof to represent 
the characters assigned, or the number of characters that had 
been read from the input stream and transferred into the string 


array "text". 


l. Input Assertion: A4 
2. Output ASSertron: A15 


3. Intermediate Assertions: 

A5 through A14. Verification conditions are provided 
for all possible assertion-to-assertion paths in the following 
paragraphs. 

4. Path A4 to AS 
The verification condition is: 
2<=4<=256 A ca=0 A 4t=80 A cb=blank 
A n=((%-1)div 2£t)+1 A ix=1 => 
2<=2<=256 A ca=0 A 2£t=80 an 1x=1 
Ane 1A na 2-1) div so) 2) 
Given the truth of the antecedents, the consequents are shown 
true as follows: 

a. 2<=2<=256 A ca=0 A &t=80 A ix-l: 

these predicates are just a restatement of antecedents which 


have not been affected by the intervening program statements. 
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procedure read.and. write. input. cards; 
comment read input cards according to given length of. text: 
begin 


A4: ( 2G=1<=256 A ca78 A 1t780 A cb=blank ) 
Integer number..of „input cards; 
number -o f.„input- carda:=( length. of -text — 1) div cardlimit + 1: 
ix:21; comment reset text index; 


AS: ( 2<=1<=256 “A ca=0 A 1t:80 A ixl A n>=l1A n=((1l-i)divB89)+1 ) 


for card counter:=I step | 


A6: C€ Cix-l) rem86=9 —>e=(( lx-1)div80)+i ) 
AT: { X=ixz-ic-1A (ix-iti=—> ctzn) ) 
AB: C “(Cix-i)remB0=0) => c=((ix-i)divB0)+2 ) 
A9: ( (ix-i=1 =>c>n) A ((ix-1)rem80:=0 y ix-12=1) ) 
A10: C 2<=1<=256 A ca=six-1 A 1t:80 A n=lA n=1f((1-1)divB80)+1 2 
untll number-_of..input..cards do 
begin 
write(lcard_-counter); 
writeon(" "); 


readcard(cardbuffer); 

writeon(cardbuffer); 

bufferposition:=9; comment reset index; 
while 


All: € @=bp<elt @< =ix-1< 1 (ix-1-bp)remB0=:0 Ai0 
cb=string of next 80 or fewer characters ) 


(Cix<=length_ofutext) and (bufferposition<cardlimit}?) do 
begin 
text(ix):=cardbufferí(bufferposition!l); 
A12: (€ 2X=1<=256 A 1t:80 A n>=l A n=f((1-1)div80)+1 
A cb=atring of 8@ characters ) 
A13: ( caslx A 9=bp<1t A lí=ixt=1l A Cix-1-bp) remBO=9 ) 


Ix:=ix+l; 
bufferposltion:=bufferposition+i; 


Al4: € AIZA 8<=1x-1<=1 A ca=ix-1 A [(bp=80 A (1x-1)rem80=0) y ix-1=11 ) 


end; comment done for ali characters ob a card: 
end; comment done for all cards: 


Al5: (€ ix-l=1x cas=sl A 2<=1<=266 A it=-80 ) 


end read „and „write input- cards: 


FIGURE 4 


PROCEDURE READ-AND-WRITE-INPUT-CARDS 
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b. n=((4-1)div80)+l: 


follows from n=((4-1)div 4t)+1 A 4t=80. 


c. n>=l: 
m=( (2-1) divs0)+1; 
4222 —29 L-1>=1; 
2-1 =1 => (2-1)div80>=0; 


therefore n>=1. 


5. Path A5 to A6-10 
The verification condition is: 
AS A c=l = A6 ^ A7 ^ A8 ^ A9 ^ A10 

The verification condition is proved by considering the conse- 
quents one at a time: 

a. (ix-l)rem80-0 — c-((ix-1)div80)*1 {A6}: 
from A5, ix=l; 
= > ((1x-1)d80)+1=0=1 
because c has been set equal to 1, the consequent of the above 
conditional is true, and the conditional is true regardless of 
the truth of the antecedent. 

b. O<=ix-1<=2 {from A7} 


ix=1 => ix-1=0, and 2>=2. 


C. 1x-1<% => c<=n (irom AN: 
c=1 and n>=1, therefore c<=n, and the conditional must hold. 
d. — ((ix-1)rem80=0) => c=((ix-1)div80)+2 {A8}: 
1x=1 => ix-1=0; thus (ix-1)rem80=0 is true; 


so. —3((ix-1)rem80=0) is false, 
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and the conditional is true. 

e.  (ix-1=% =>c>n) A ((ix-1)rem80=0 V ix-1=2)  (A9) 
ix-1=0 and 2£>=2, so ix-1=2 is false, and the conditional is true, 
and (ix-1)rem80=0 is true, and therefore the disjunction is true; 
thus, A9 must hold. 

f. casix-l (from A10]: 


ca=0 and ix=1 is sufficient for ca=ix-l1. 


g. the remainder of assertion Al0: 
these predicates are just a restatement of antecedents which 


have not been affected by the intervening statement. 


6. Path A6-10 to All 
The verification condition is: 
A6 A A7 A A8 A ADO A AIO A c<=n A bp=0 
A cb=string of next 80 or fewer characters => All 
Again the consequents (predicates of All) are considered one at 
a time. 
a. 0<=bp<=4t: 
this follows from bp=0 and 2t=80. 
poc tixcpbsbp)rems0-05 
u-cne» —(c»m); 
— (con) A (ix-1=%2 —» c»n) —» —(ix-1-226); 
— (ix-1-2) A ((ix-1)rem80=0 v ix-1=2) => (ix-1)rem80=0; 
finally, (ix-1)rem80=0 A bp=0 => (ix-1-bp)rem80=0, 
which is that which was to be proved. 
Co. The remainder of the predicates: 
these predicates are just a restatement of antecedents which 


have not been affected by the interveining statements. 
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TOES Bach All tocALZZIS 
The verification condition is: 
All A ix<=4 A bp<2t a text(ix)=cb(bpl1) =>A12 A Al; 

The consequents of the verification condition are considered 
one at a time. 

a. ca=ix (from AÍ3): 
ca=ix-1 A text(ix)=cb(bp]1) is sufficient for ca=ix to be true. 
text(ix) is the ix-th character, and it is assigned a value in 
this program fragment (that it is the proper value is shown 
Shortly). If ix-1 characters have been previously correctly 
assigned to text, and one more character is assigned, then ix 
characters have been assigned when control reaches assertion Al3. 
In Algol-W, the string indexed by bp|l is a string of length 1 
(1.e., a character) at position bp in the larger string (cb); 
the first position is 0, and the 80th is 79.  O<=bp<4t guarantees 
that bp is in range; "cb=string of next 80 or fewer characters" 
ensures that the proper characters are in the buffer, and 
(ix-1-bp)rem80=0 means that ix and bp*l (the next character to 
be assigned in text and the next character in the buffer avail- 
able for assignment) always differ by a multiple of 80, which is 
correct when an 80-character buffer is used. So the proper 
character is being assigned on this control flow path. 

b. 0<=bp<tt {from Als}; 
O<=bp<=4t A bp<4t => 0<=bp<kt. 

C. 1<=ix<=2 (Erom Al I: 


O<=1x-1<=2% A 1x<=2 => l<=1ix<=4. 
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C. ]<=1x<=2 (From ALS}: 
O<=ix-1<=2%2 A 1x<=2 = 1<=ix<=2. 
d. Al2 and remaining predicate of Al3: 


these predicates are just a restatement of antecedents. 


8. Path Alz=15 to All (return to start of Loop) 
The verification condition is: 
AIZ TATAI, ix:six*1; bp:s-bp-«1 (A11) 
The verification condition as expressed above is rewritten as 
follows, replacing ix and bp by ix+l and bptl in assertion All 
(as the assignment rule of inference requires): 
AT2 ^A A13 => 
[0<=bptl<=-Lt A 0<=Ix<=4 Y [1X=bp=1) Tens0=0 A 2<=8<=256 
o E C= OO Ne = An Erd eA] 
^ Cbsstring of next 80 or fewer characters] 
The verification condition is once more proved by considering 
the consequents one at a time. 
a. 0O<=bp+1<=2t: 
0O<=bp => 0<=bp+1; and since only integer arithmetic is permitted, 
bp<2t =>bp+1<=2t. 
b. the remainder of the consequents: 


restatements of predicates of AlZ and Al3. 


9. Path All to A14 
The verification condition is: 
ALL SAFE IX ADB => A14 
The proof is constructed by showing the consequents of the veri- 


fication condition one at a time. 
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a. [(bp=80 A (ix-1)rem80=0) Y ix-1=2]: 
— (ix<=2 an bp<4t) means that either ix>4 or bp>=4t, or both. 
Consider 1x>2 as case l; 
1x>2 ^ O<=ix-1<=2 => L<1ix<=L+1, 
so ix=L+1l and 1x-1=% , in which case the consequent is true. 
Consider bp>=%t as case 2; 
bp>=2t A 0O<=bp<=2t => bp=1t; 
£t=80 A bp=2t => bp=80; 
bp=80 => (ix-1-bp)rem80=(ix-1)rem80; 
since (1x-1-bp)rem80=0, thén(ix-1)rem80=80, 
and the consequent is true. 
So in either case the disjunctive consequent holds. 
b. the remainder of the predicates: 


these predicates are just a restatement of antecedents. 


10. Path A6-10 to Al4 
The verification condition is: 
{A6 A AT A ABAASAAlO} F; while C do P [A14] , 

where F represents the statements between AO-10 and the while 
Statement, C represents the predicate of the while statement 
and P is the while loop body. The previous proofs of the 
verification conditions for paths A6-10 to All, All to Al2-13, 
A12-13 to All, and All to Al4 satisfy the requirements of the 
pulcuot inmcterence fonewhlle statements, and therefore the 


verification condition for path A6-10 to A14 is proven. 


11. Path A14 to A6-10 


The verification condition after substituting ctl for 
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c in assertions A6-A9 (as required by assignment rule applicable 
Porno mee I topl" which increments €) is: 
A14 => [((1x-1)rem80=0 => c+1=((ix-1)div80)+1) 
A Q<=ix-1<=2% A (1x-1<4 => c+l<=n) 
A(x- rene0=0) = crl=((1x-1)d+v80) +2 
A (ix-1=% => c+lon) a ((ix-1)rem80=0 v ix-1=4) A Al0] 
The proof of the verification condition is shown for each con- 
sequent. 
a. AlO A 0O<=ix-1<=2 A ((ix-1)rem80=0 v 1x-1=2): 
these predicates are just a restatement of antecedents. 
b. (ix-1)rem80=0 => c+1=( (ix-1)div80)+1: 
In addition to being a counter for the for loop, "c" is a 
count of the number of data cards that have been read, because 
there is exactly one readcard statement in the for loop body. 
ca=ix-1 is the number of characters that have been assigned 
from the buffer into the array "text"; each time the loop is 
executed, 80 characters are assigned into "text", except 
that the last time the loop is executed, from 1 to 80 characters 
may be assigned. 
Dt (ix-1)zems0-0, an even multiple (namely (ix=bjdaycl) of 80 
meharacters have been assigned, and loop ñas Den executed that 
number of times as control returns to A6-10; thus, c+1 (the 
new value after the step) is then one more than that number, or 
etla Ix-bydBve0)*1. Therefore the consequent holds, 
c.  =((1x-1)rem390=0) =>e+15((1x=1)0d1/480)+2: 
The proof for this consequent is similar to the preceding, ex- 


cept that because (ix-1)rem80 is not equal to zero, less than 
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80 characters have been read when control returns to A6-10, and 
the loop has been executed one time more than in the case above. 


Thus, c+1=((ix-1)div80)+2; q.e.d. 


de ie- == Erl=>1: 
If ix-1<%, then since 
xt Y (CIX-1)5emB0-0) (proved above), 
nt must be that (1x=1)rems80=0. 
Therefore, from the above proved conditional, 
er l=((ax-2)dives0'l as true, 
and ix-1<4 => ix-1<=4-1, 


so c+l<=((4-1)div80)+1. 
Then because ((4-1)div80)+l=n, c+l<=n. 
a. ix- = Cr] >n: 


There are two possibilities. 

birst, assume ~((1Xx-1)]remo0=0. 
Mmenctl=((1x-1)div30)+2, 

and 'c+1>((1x=1)d1Vv80)+1. 

If ix-1-2-2, then ix-1»2-1 and 

(4-1)div80 =(ix-1)div80; 

miewerore cCrl7( (2-1)diveG)jrl, thus clon. 
Second, assume (1x 1)rems80-0. 

henge 1=( (ix=1 dose) +], 

amdssınce 2=1x-], % nem 80-0 

and (4-1)div80<4 div 80. 

Therefore cri>((1%-1)]4iv80)+1, thus e+lon, 


In either case, c+l>n and the consequent is proved, 
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12. Path A6-10 to Al5 
The verification condition 1s: 
A6 ^ A7 ^ A8 ^ A9 ^ Al0 A con => 
1x-1=4 A ca=4 A 2<=2<=256 A 2t=80 
2<=2<=256 and 4t=80 are restatements of predicates contained 
in the antecedent of the verification condition; the remaining 
two predicates are verified as. follows: 
a.  ix-l1-22: 
1x-l«£ => c<=n is true (an antecedent), so the contrapositive 
is also true: 
Cones (ix-1)»52, 
since c>n, 1x-=1>=%, 
Also, 0<=ix-1<=2 (an antecedent), therefore ix-1=2 
b. ca=?: 


ca=ix-1 A ix-l=2 = cast, 


15. Path AS to Al5 
The verification condition is: 
AS for statement {Al5}. 
The previous proofs of the verification conditions for paths 
A5 to A6-10, A6-10 to A14, A14 to A6-10, and A6-10 to Al5 satis- 
ty che requirements of the tor rule, taeretore the Vveritication 


condition for this path is proved. 


14. Input Assertion to Output Assertion 


The proof of partial correctness for this procedure 


is completed by concatenation of paths A4 to A5 and A5 to Alo. 
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15. Termination 
During the preceding proof of partial correctness, the 

reader should have been risa that the procedure terminates 
by the relations among ix-1, c, and n, and by those among ix, 
2, bp, and £t. If not, termination is assured because the program 
has one entry and one exit and is a concatenation of assignment 
statements and a tor statement. The for statement terminates 
if its loop body terminates; in this case, the body terminates 
provided the while loop eventually terminates. 

The formality of well-ordering could be applied to show the 
non of the while statement; however, termination is 
evident since "£t" is fixed at 80 and "bp'" starts from 0 and is 
incremented by one on each execution of the loop body (which 
terminates as it has no loops). Thus "bp" must eventually exceed 


"£t" and the while statement must terminate (it may terminate 


earlier if ix=2). 


H. PROCEDURE PALINDROME+CHECK 
Figure 5 contains the assertions for this procedure, 
l. Input Assertion: Ar: 
2. Output Assertion: A47-29. 
3. Intermediate Assertions: 

A18 through A26. Verification conditions are provided 
for all possible assertion-to-assertion paths in the following 
paragraphs. 

4. Path Al7 to A18-22 


The verification condition is: 
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procedure palindrome_check; 
comment find all pallndromes within given text string; 


begin 
A17: ( 2<=1<=256 ^ cn*1^ Jx*1 ) 


comment scan text from left to right; 
for ix:=2 step l 


A18: ( 2%=1<=256 A ca=1 A jx>8 A 2<=ix<=1+1 ) 
A19: ( Wx[(2(=x(=1x-1 A text(x-1)=text(x)) => 
3yCKy&Jx ^ 1Gzboply)(=x-( A xt=zeopíly)<=1)] ) 
A20: CC Vx[(3<=x<=1lx-1 A textíx-2)=text(x))—> 
Byly< yx A 1G=boply)<=x-2 A x(zeop(y)(=1)] ) 
A21: ( Vyl( (OX y&)x ^ bop(Cy)?1 ^ Aleop(y)(1) => 
mí text(boply)-1)=text(eop(y)+1))] ) 
A22: ( Vyl (0<y<3x A “Ceopl y)=0)) => 
[stringíbopl y) ,eopl y))=0k A bopíly)>=i ^ eoply)“=1 
N Wz (062% ya A w(z7y)) 77 
(~Cbop(z)=boply)) A Chopl(z)<boply) = eoplz)<eoply)))} 31 J > 


until length_of_text do 
begin 
lf text(1x-1) = text( ix) then continue checklng((ix-1), ix: 


A23: C 2<=1<=256 A cal A jx>8 A 2G=ix(=1A A20 A A21 A A22 ) 
A24: ( Vxí(2(=x(six A text(x-1)=text(x))= 
Syly< yx an 1<=boply)<2x-1A x<=eoply)<=1)) ) 


if ix ve 2 then 
if text(ix-2)=text(ix) then continue -checking((ix-2) iz); 


Aga: ( A23 ^^ A24 ^ A21 ^ A22 3 

A26: | ( Vxl(3(=x(=ix A text(x-2)=text(x))-—> 
AyCyCJx ^ Ó|E*7bop(y)ózx-2 ^ x<zeoply)<=1)] ) 

end ; 

A27: CC 242142256 ^ cal A jx>8 A A21 A A22 ) 

A2B: ( Vxl(2X7zxézlA text(x-1)=text(x)) => 
dyCGyC6Jx ^ ]W7bop(y)X(7x-1 ^ x(zeopCy)£71)0] ) 

A29: ( vx[ (3X 2x£*1 ^ text(x-2) "text(x)) — 
Syly< yx A 1<=boply)<tx-2A x<=eoply)<=1)) ) 


end pallndrome_check; 


FIGURE 5 


PROCEDURE PALINDROME~+ CHECK 
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A17 M ix=2 =>A18 A Al9 ^ AZO0 ^ A21 A A22 


Proof is shown by considering the consequents one at a time. 


a. 2<=%<=256 A ca=2%2 {from A18}: 
These two predicates are a restatement of part of the input 
assertion. Their truth is not modified in this procedure, and 
they are repeated in all intermediate assertions. They will 
not be discussed in the discussion of the remaining verification 


conditions for this procedure, 


b. 3x9 (from A18}: 


jx=1 => 3x>0. 


C. 2<=ix<=2+1 [from A18}: 


(C2 A 2452) > 2S=1x== +1, 


di. ALI: 
No x can satisfy the antecedent 2<=x<=ix-1 because ix-1=1; 
Brbererore the condrtwonal is true. 

6. A20; 
This consequent is similarly true. 

A A 
No integer y can satisfy the antecedent 0<y<jx because jx=1; 
therefore the conditional is true. 

Be A22: 
Similarly. 

5. Path ABS 2270 R27223 
The verification condition is: 


PERA AO A APO A A21 A A822 A 101 =ANZ7 A A23 ^A A29 
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The consequents are all restatements of the antecedents except 
A28 and A29; proofs of their validity follow: 

a. A28: 
1x<=2 +] ^ ix» => ix-l=4. 
Therefore assertion A28 is a restatement of A19 with 2 replacing 
ix-l in the first predicate of the antecedent, and the assertion 
holds. 

b. A29: 


This assertion holds similarly. 


6. Path A18-2Z2 to A25-24, Case I 
Case 1 for this path is arrival of control at assertions 
Roles diter execution Of Ehe 1f Statement with true predicates. 
In this case, the verification condition is: 
ALS A AI9 A A20 a AcE A ALL ^ 
ix<=4 A text(ix-1)=text(ix) => A23 A A24 
The following condition, deducible from the antecedents of the 
verification condition, becomes the input assertion to procedure 
"continue-checking" whenever the actual parameters 'ix-1" and 
"ix" are replaced by the formal parameters "first" and "last": 
2*-5«2290 4x Ca=t A IX>0 A 1e=1x=1<=0=L 0 2<=1x<=2 
A ix=isic X pext(Ix-L|stext(1xX) ^A. A21 7S AZZ 
The output specification of the procedure "continue-checking," 
after replacing "current" by the value "current" was assigned 
at the procedure call in the proof of correctness of that pro- 


cedure, namely the value "ix", is: 
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A21 A A22 ^ 2<=% <=256 A Ca=£2 A 3x>0 ^ 

Ay(y<jx ^ l<=bop(y)<=ix-1 A ix<=eop (y)<=2) 
Given that the procedure 'continue+checking" has been proven 
correct (presented in the next section of this appendix), all 
requirements for the rule of inference for procedure calls have 
been satisfied, and the output assertion of 'continue+checking," 
as rewritten above, can be used to show the truth of assertions 
A23-24. In fact, assertion A23 is entirely a restatement of 
either this output assertion or the antecedents of the verifi- 
Cation condition. Assertion 19 ensures the validity of assertion 
A24 over the range of x from 2 to ix-1; 
(text(ix-1)=text(ix) (an antecedent) 
and Aylysjx A een 1x<=eop(y)<#=2) 
(from the output assertion of "continue checking") together 
extend the range of x to ix, and therefore assertion A24 holds. 


Thus the verification condition for this case has been proved. 


7. Path A18-22 to A23-24, Case 2 
Case 2 is the case when the if statement preceding 
A23-24 is executed with the predicates false; in this case, the 
verification condition is: 
A18 ^ A19 ^ A20 ^ AZ1 ^ A22 ^ 
ix<=L A + (text(ix-l)=text(ix)) => A23 ^ A24 
All of the conseguents but A24 are a restatement of antecedents; 
A24 is a restatement of A19 with the range of x increased to 
include x=ix, the ix-th value having been checked for compliance 


with the assertion in the current iteration of the for loop. 
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Since the antecedent of the conditional contained in assertion 
A24 is false in this case for x=ix, the conditional is true for 
x=ix, and assertion A24 holds. Thus the verification condition 


1s proved. 


8. Path A25-24 to A25-26, Case | 

This first case occurs whenever ix=Z, or 
when =(ix=2) and also —(text(ix-2)=text(ix)); 
in this case, no call is made to procedure "continue+checking", 
and the verification condition is: 

A23 ^ A24 —» A25 ^ A260 

Assertion A25 is a restatement of antecedents, and assertion A260 
is just assertion A20 with the range of x extended to include 
x=ix. The conditions for this case ensure that for x-ix the 
antecedent of the conditional contained in A26 is false; either 
ix=2 and 3<=x is false or 
A(text(ix-2)stext(ix)). Therefore the conditional is true for 
x=1ix and thus assertion A26 holds; the verification condition 


1s proved. 


9. Path A23-24 to A25-26, Case 2 
In this case the call to "continue+checking" is executed, 
and the verification condition is: 
A23 ^- A24 A nl(ix=2) A text(ix-2)=text(ix) 
=> A25 A A26 
Similarly to the proof for the previous path containing a call 


to procedure "continue<checking", it may be shown that the 


antecedents of the verification condition satisfy the procedure's 
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input assertion and that the output assertion, together with 
the antecedents, satisfy assertions A25-26. In assertion A26 
the range for the universal quantifier x is extended to include 


the case x=1x as before. 


10. Path A25-26 to A18-22 
The verification condition is (substituting ixtl for 
ix in A18-20 because of the assignment): 
A25 A A26 —» A21 ^ A22 ^ 
2<=4<=256 A ca=4 A jx>0 ^ 2<=ix+1<=2+1] 
A Vx[(2<=x<=ix A text(x-l)=text(x)) => 
dy(y«jx ^ 1<=bop(y)<=x-1 A x<=eop(y)<=%)] 
^ Nx[(3«zx«zix ^ text(x-2)=text(x)) = 
INVEST ^ 1-535597] x52 ^ X<=eop(y}<=2) | 
All of the consequents but 2<=ix<=2g+l are restatements of 
antecedents; 
and 2<=1x<=2 => 3<=1x+1<=2+1, thus 2<=ix+1<=2+1 is true and 


the verification condition is proved. 


11. Path Al7 to A27-29 
The verification condition is: 
(A17) for statement  (A27-29] 

The previous proofs of the verification conditions for paths 
A17 to A18-22, A18-22 to A23-24 to A25-26, A25-26 to A18-22, 
and A18-22 to A27-29 satisfy the requirements of the for rule; 
therefore the verification condition for this path is proved, 
thus completing the proof of partial correctness for this 


procedure. 
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12. Termination 
The procedure has one entry and one exit, and the only 
loop is a for statement, which have been shown to terminate. 


Therefore the procedure terminates. 


I. PROCEDURE CONTINUE+CHECKING 

Figure 6 contains the assertions for this procedure, A 
constant "current" is introduced in the proof and the assertions; 
this constant is given the value of "last'" at the time of the 


procedure call. 


a Input Assertion: AS0=524 
Zs Output Assertion: Ase. 
Sa Intermediate Assertions: 


A33 through A37. Verification conditions are provided 
for all possible assertion-to-assertion paths in the following 
paragraphs. 

4. Path A30-32 to A33 

The verification condition is: 

A30 A A31 A A32 A p=true => A33 
The consequent is a restatement of the antecedents with the 
addition of the predicate "current=last,' as mentioned above. 


Thus proof of the verification condition is immediate. 


5. Path, A33 to A354 
The terminology "string(first,last)-ok" used in these 
assertions indicates that the substring from text(first) to 
text(last) is a valid palindrome. The verification condition 


M 


tor this path is: 
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procedure continue checking (Integer value first, last): 

comment Given first and last ase pointers to a palindrome 
of size 2 or 3, this procedure checks whether or not thle 
pallndrome Is included In a larger palludrome; 

begin 


AJO: C 2<=1<=256 A ca=l AX jx>8 A 1c=flrst(=1-1 A 2c=last=1A firs*X inst 
A text(first)=text( last) ) 

A31: © Wyl(@y<yx A boply)> 1% 9X«eopCy)C 1) — 

m(text(boply)-1)=text(eop(y)+1))] ) 
A32: (C Wyl (O<y¥<yu A ~Ceopl y) =O) ) => 

Cstring(boply) ,e0oply))=o0k A boply)>=1 A eoply)<=1 

^ Yz( (0€zéJx ^ -(z2y)) — 

(~(bop(z)=boply)) A Choplz)<hboply) =—9 eop(z)4^eop(y5?? FJ ] 53 


logical palindrome; 
pallndrome:=true; 


A33: C A308 A A31 A A32 A pš true A current=last ) 
while 


A94: ( A30 A A31A A32 A currentc= last A string( first, last)=ok 
A (p= false => +( text(first-1)=text(last+1))) ) 


((fiIrst> 1, and (last<length. of. text) and (palindrome“ true) do 
begin 
if text(first-1) = text(last+ri) then 

begin 

comment larger palindrome found; 

first:-first-1: 

last:-1last-*1; 


A35: (€ A34 ) 


end 
else 
begin 
palindrome:-false: comment largest palindroire found; 
A36: (C A34 ) 
end; 


e nd ; 


A37: (€ AJO ^A AJIA A32 ^ currentí*last ^ string(ilrst,last;-»ok&k 
A (flrst=1 v last21 Y “(text(f Irst-1)=textí( last+1))) ) 


record_palindrome( first, last); 


ASB: ( A31 A A32Q A 2<=1<=236 A ca=1l ^ jyxoO ) 
A Ayly<gx A 1<=boply)=current-1 A current*=eopí y)<=1)> 3 


end contlinue_checking: 


FIGURE 6 


PROCEDURE CONTINUE-CHECKING 
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A33 > A34 
The consequents are considered one at a time. 
a. A30 A A31 ^ A32: 


these predicates are just a restatement of antecedents. 


b. <urrent<- last: 


follows directly from current=last. 


c. string(first,last)=ok: 
static analysis of the program showed that, for all calls to 
this procedure, either first-last-l or first-last-2 (this 
could have been a predicate of the input assertion), and this 
fact and text(first)stext(last) ensures that string(first,last) 


is a palindrome when control reaches assertion A34 from A335. 


d. p-false —» 1(text(first-1)=text(last+l): 
Since p=true, the conditional is true regardless of the truth 


of the consequent. 


6. Path A354 to A35 
If program control reaches assertion A35, then the 
predicates of the while and if statements are true and the 
verification condition for this path is (substituting first-l 
and last+l for first and last in the consequent, due to the 
assignment statements): 
A34 ^ first»l ^ last<Z A p=true 
A text(first-1)=text(last+1) => 
2<=2<=256 A ca=% A jx>0 A 1<=first-1<=%-1 ^A 2<=last+1<=2 
A first-1<last+l A text(first-1)=text(last+1) ^ A531 A A32 


A current<=last+l A string(first-1,last+l)=ok 
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The consequents of this verification condition are considered 
one at a time. 

a, 25326-25960 A pact ^A jx: 
these predicates are just a restatement of antecedents; they 
remain valid throughout this procedure and will not be discussed 
during the proof of further verification conditions. 

b. 1<=first-1<=2-1: 
l<=first<=4-1 A first>l > l<= first-1<=2-1. 

C. 2<=last+1l<=2: : 
2<=last<=2 A last<% => 2<=last+1<=12. 

d. £first-l<lasttl: 
follows directly from first<last. 

e. text(first-l)=text(last+l) A A31 A AS32: 
these predicates are Just a restatement of antecedents. 

£. cumrepnt«slasttl: 
follows directly from current<=last. 

g. string(first-1l,last+1)=ok: 
string (first,last)=ok A text(first-1)=text(last+1) 
=> string(first-l,last+l)=ok. 


This concludes the proof of verification condition. 


7. Path A34 to A36 
If control reaches assertion A36 from A534, then the 
predeeate o the while statement is true, that of the af state- 
ment false, and the verification condition is: 
A34 ^ first>1 A last<2 


A (text(first-1)=text(last+l)) A p=false =>A34 
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The consequents are shown one at a time, 

a. psfalse => —_(text(first-1)=text(last+1)): 
the antecedent and consequent of this conditional are both true 
(antecedents of the verification condition); therefore, the 
conditional is true. 

b. the remainder of the consequents: 


these predicates are just a restatement of antecedents. 


8. Paths A35 to A34 and A36 to A34 
Since A35 and A36 are each identical to A34 and since 
there are no program statements on these paths, the verification 


condition is A34 => A34, which must be true. 


9. Path A34 to A37 

The verification condition 1s: 

A34 ^ ^(first?l ^ last«£ ^ p=true) => A37 
The consequents are considered one at a time, 

a.  |first=l v last=2 

Y A(text(íftirst-1)=text(laste*t))]1: 
from the antecedent — (first>1 A last<4 A p=true), 
DeMorgan' Rule gives: 
first<=1 V last>=4 Y p=false. 
Since also first>=4 and last<=4 , and 
Since p=false = > (text(first-l)=text(last+l), 
the above is equivalent to: 
first=1 V last=4 V +1 (text(first-1)=text(last+l1)); 


thus the conseguent is shown. 
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b. the remainder of the consequents: 


these predicates are just a restatement of antecedents. 


10. Path A33 to A37 
The verification condition is: 
{A33} while statement (A37) 
The previous proofs of the verification conditions for paths 
A33 to A34, A34 to A35, A34 to A36, A35.to A34, A36 to A34, 


and "AS4 to A3S/ are sutficient to show this verıfıcatıor condition. 


J1. Path A37 to A38 
Assertion A37 satisfies the input assertion to proce- 
dure "record-palindrome" (in this case the names first, last 
and current retain the same connotations).  Assertion A38 is 
precisely the output assertion of '"record-palindrome." Therefore 
the verification condition for path A37 to AS8 is verified by 
the proof of correctness for the called procedure (in the next 
section). 
12. Input Assertron to Output .AsSsSertron 
The proof of partial correctness for this procedure 
is completed by concatenation of paths A30-32 to A33, A33 to 
25/7, and A5/ to A59. 
15. Termination 
Procedure "continue+checking'" has one entry, one exit, 
and but one loop, the while statement. Assuming "record+palin- 
drome" terminates (proven elsewhere), this procedure terminates 
1f the loop terminates. Clearly the loop body terminates, so 


loop execution will terminate if one of the three conditions: 
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first>1l1, lastel”. 0r p=true 
ever takes on a value of false. Since initially first>=1 and 
"first" is decremented by 1 on each loop iteration for which "p" 
is not set equal to false (in which case termination would be 
assured), then the well-ordering principle of-the natural numbers 
requires eventually first<=1 (unless the loop terminates sooner). 


So the procedure terminates. 


J. PROCEDURE RECORD+PALINDROME 


Figure 7 contains the assertions for this procedure. 


I Input Assertion: A39-41. 
2; Output Assertion: A51-52. 


3. Intermediate Assertions: 

A43 through A48. Verification conditions are provided 
for all possible assertion-to-assertion paths in the following 
paragraphs. 

4. Path A39-41 to A42-44 

The verification condition is (substituting 1 for i 
in assertions A42 and A44 because of the assignment to the 
Tor loop Counter]; 

A39 ^ A40 a A41l ^ entry=true =5> 
A39 A A40 A A41 A 1<=jx A A43 A 
[ (entrytrue A ~ (eop(0)=0)) => Yz[0<z<j => 
( —(bop(z)=first) * (bop(z)<first => eop(z)<last))] ] 
The consequents are considered one at a time. 
a. A39A A40 A A4l: 


these predicates are just a restatement of antecedents. 
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bs. l1es3xX* 
follows directly from jx>0. 
Es ASS: 
Since entry=true, the antecedent of the conditional is false 
and the conditional is true. 
d. the remaining complex predicate: 
Since there is no integar z satisfying 0<z<i, the consequent 
of the antecedent of this predicate is fuer and the conditional 
is shown; thus, the final consequent of the verification con- 


dition is proved. 


5. Path A42-44 to A45-46 
In the event control passes to assertion A45-46 from 
A42-44, the predicate of the intervening if statement is true 
and the verification condition is: 
A42 A A43 A A44 A i<=jx-1 A first>=bop(i) 
A last<=eop(i) A entry =false =>A45 ^ A46 
Proof is by considering the consequents one at a time. 
a. A39 ^ A40 ^ AA] from A45]: 
these predicates are just a restatement of antecedents. 
b. i<=jx-l {from A45]: 
this predicate is a restatement of the antecedent resulting from 
the test on the loop counter. 
c. entry=false =  dy(y«-jx ^ l<=bop(y)<=current-1 
A current<=eop(y)<=2) {A43}: 
entry=false is true; thus it must be shown that there exists 


a value for y such that the predicates following the "existential" 
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A39: 


A40: 
A4i: 


A42: 
A43: 
A44: 


A45 : 
A46: 


A47: 


A48: 


procedure recor 
comment Record 
record 
specif 
Jx was 
next e 
begin 


C 2G=1<=2256 A ca=l A Jx>8 A ic=firsatC=1-1 A 2C=lastc=1 A First dast 


A current = last 


d_palindrome (integer value first, last); 
oniy max iength palindromes. Fiag previousiy 


ed palindromes if they are included in the palindrome 


ied by first and last. 


initiaiized to 1. After completion jx points to the 


ntry in begin_of_palindrome and end_of_pailialrome; 


A string(first,last)=ok 


A (flrst=1 v last=1 Y “Ctextífirst-1)=textí(last+1))) 3 


[ Yyl[ (0 y Jx ^ 


boply)> iA ®&eoply)<i)> 


~(text(boply)-i)=textleop(y)+1))] 2 
€ Vyl (0€yX Jx ^ "(eopéCy)29))—2 


[string(bop( 
NA YZE (OZS 
(~( bop 


integer i; 
logical entry; 
entry: =true; 
for 1:=1 step l 


y) ¡,eopl y))=0k A boply)>=1 A eopíy)<=i 
JX ^ "(z2y))-— 
(z)=boply)) A Chop(z)<boply) => eoplz)*eoply))) )] 


comment local counter; 


( A39 ^ A40 ^ A41^ ii(72Jx ? 


( entry=false =—>ldy(yx=¿x A lí=boply)“=current-1 A currentí =eopí y)<=1) 


( Tentry true A 


Vzixzi -— 


until Jx-1 
begin 


“(eopíl i-1)=0)) => 
(~(bop(z)=first) A (bop(z)<first => ecp(z)< last))] 


do 


if ((first>=begin_of—_palindrome( i) ) 


and ( 
begin 
comme 


last<=end_of_palindrome(i))) then 


nt Palindrome is entirely included in a previousiv 
recorded paiindrome. No entry required: 


entry:=false; 


C A39 X A408 A A41 A IG=Jx-1 A A43 ) 


( (entry=true A 


~Ceop(i)=0)) => 


yzlaczí=i => (“(bopíz)=firet) A (bopíz)<first = > eoptz)<iast))) 


end 
else 

begin 

if (( 


( A4D ^ A46 ) 
end; 
( A45 ^ A46 ) 


end ; 


begin-of-paiindrome(Ci) »- first?) 

and (end.of.palindroie(i) <= iast)) then 
begin 

end-of_palindrome(i):=%; 

comment flag smaller paiindrome; 

end; 


comment Ali previously recorded paiindromes 
compared with last input; 


FIGURE 7 
Page 1 of 2 


PROCEDURE RECORD+PALINDROME 
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A49: ( A39 A^ A40 A A4l ^ A493 ) 
A50: C (entry=true A “(eopíyx)=0)) => 
VzlO<zs jx =>(“(boplz)=first) A (bopíz)<first => eoplz)< last))] ) 


if entry = true then 
begin 
comment larger than all previous or overlapping or disjoint; 
begin of „palindrome( jx):=first; 
end_of_palindrome(jx):=last; 
Jx:7Jxtl; 
end; 


ASI: CC A40 ^ A41 ^ 242142256 A cazl A ¿x>9 ) 
AS2: (C Ay(y<gx A 1<=boply)=current-1 A current<=eopíy)<=1) ) 


end record_palindrome; 


i^ 


FIGURE 7 
Page 2 of 2 


PROCEDURE RECORD-PALINDROME 
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quantifier hold. 
It is proposed that y-i will satisfy those conditions. 
Since i<=jx-l, i<sjx holds. 
i<jx A A4l = bop(i)>=1; 
current<=last A first<last => current-1<=first; 
current-1<=first A bop(i)<=first => bop(i)<=current-1; 
therefore 1<=bop(i)<=current-1 holds, 
current<=last ^ last<=eop(i) => current<=eop(i); 
i<jx A A41 = eop(i)<=4; 
so current<=eop(i)<=2 holds. 
Therefore, the necessary predicates are all true when y is 
chosen equal to i; this consequent of the verification condition 
is proved. 

d. A46: 
Since entry=false is an antecedent of the verification condition, 
entry=true is false and the conditional which is assertion A46 


is true, 


6. Path A42-44 to A47, Case 1 

Control can pass to assertion A47 from A42-44 either by 
executing the compound statement with the comment "flag smaller 
palindrome" or by failing to execute that compound statement 
When the predicate ot thes preceding if ts false. Por case], 
the case where the predicate is false, the verification condition 
is: 

A42 A^ A43 A^ A44 ^ i<=jx-1 ^ 
~ (first>=bop(i) A last<=eop(i)) A 


=(bop(i)>=first ^A eop(i)<=last) 
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=> A47 
All of the consequents contained in A47= A45 A {A46} except 
A46 are restatements of the antecedents. 
a. (entry=true A —(eop(i)=0)) => 
Nz[0<2<=1 => ( S (bop(z)=first) A 
(bop(z)<first => eop(z)<last))| {A46 } 
If entry=false, the conditional is true without further proof. 
If entry=true A “(eop(i)=0), the antecedent of the verification 
condition provides that the generalization on z is true for 
0<z<i; ıf it is shown to hold for z=i, then it is true for 
O<z<=1 and this consequent of the verification condition is 
proved. 
Either bop(i)=first or bop(i)<first. 
Suppose bop(i)=first; 
then either eop(i)<=last or last<=eop(i), 
and then one of first»-bop(i) ^ last<=eop(i), 
or bop(i)>=first A eop(i)<=last, must be true. 
But the antecedent of this verification 
condition indicates both are false; 
therefore  (bop(i)=first. 
Now suppose bop(i)<first; 
then first>=bop(i) is true, and 
from —“(first>=bop(i) ^ last<=eop(i)), 
it is shown that last<=eop(i) must be false. 
Thus bop(i)<first = eop(i)<last, and 
the generalization on z holds for 0<z<#=i; 


therefore this consequent is true. 
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7. Path A42-44 to A47, Case 2 
For case 2, the case where the predicate of the if 
statement immediately preceding A47 is true, the verification 
Condition is: 
A42 ^ A453 A A44 A i<=jx-1 A 
bop(i)>=first A eop(i)=0 A47 
All of the consequents contained in A47= {A45 A A46] except 
A46 are restatements of the antecedents. 
a. (entry=true A —(eop(i)=0)) => 
2 [0721 == D —(bo5(2)sSErTSt] ^ 
(bop(z)<first => eop(z)<last))] { A46}: 
Since eop(i)=0, the antecedent of this conditional is false, 
and the conditional is true; this completes the proof of the 


Merrtication condition for this path. 


8. Path A45-46 to A48 and Path A47 to A48 
There are no program fragments on these paths, so the 
verification conditions are trivially true; they are: 


A45 ^ A46 7 A45 A A46 


9. Path A48 to A42-44 
The verification condition is: 
A48 —2 A39 ^ A40 A A41 ^“ itl<=jx 
^ A43 ^ (entrystrue ^ ^(eop(i)s0))-—- 
vz l0ez=<==1+1 => (> (bopíz)=t1rst) 
A (bop(z)<first = eop(z)<last))] 


Proof is shown by considering the consequents one at a time. 


123 





a. A39 ^ A40 A A4l: 
these predicates are just a restatement of antecedents. 
D. m 
j<=jx-1 => i+1<=jx. 
Ca CASS 
this predicate is just a restatement of an antecedent. 
d. (entry=true A "(eop(i)=0)) => 
Vz[0<z<=i+1 => ( ^(bop(z)sfirst) 
A (bop(z)<first => eop(z)<last))] 
from A46 it 1s known that the generalization on z is valid 
over the range 0<z<=1, which is equivalent to the range in this 
consequent, namely 0<z<itl; therefore this consequent holds. 


Thus, the verification condition for this path is proved. 


10. Path A42-44 to A-49-50 
The verification condition is: 
A42 A A43 A A44 A 1>jx-1 = A49 A ASO 
The consequents are considered one at a time. 
a. A49: 
This predicate is a restatement of antecedents of the verifi- 
cation Condition and thus is true, 
b. (entry=true A (eop(jx)=0)) = 
Wz[0<z<=jx => ( 7 (bop(z)=first) A 
(bop(z)<first = eop(z)<last))] {A50} 
1>jx-l A 1<=jX = 1=3x. 
Therefore, this consequent is just a restatement of an antece- 


dentswitch jx=1 replacing? 1. = 
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11. Path A39-41 to A49-50 
The verification condition is: 
{A39-41} for statement {A49-50} 
The previous proofs of the verification conditions for paths 
A39-40 to A42-44, A42-44 to A45-46 to A48, A42-44 to A47 to A48, 
A48 to A42-44, and A42-44 to A48 satisfy the requirements of 
Enestor rule, therefore; the verification condition for this 


path is proved, 


12. Path A49-50 to A51-52, Case 1 

Case 1 is the case where entry=false and the compound 
statement intervening is not executed. The verification con- 
dition in this case is: 

A49 n A50 A entry=false = A51 ^ A52 
Consider the consequents one at a time. 

a. A51: 
The predicates of this consequent are restatements of given 
predicates. 

Da ASZ. 
entry=false A A43 =>A52 (A43 is one of the predicates con- 


tained in assertion A49). 


13. Path A49-50 to A51-52, Case 2 
In this case, entry=true and the compound statement 
intervening is executed. The verification condition (with 


jx+1 replacing jx in A51-52) is: 
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A49 ^ A50 ^ entry-true ^ bop(jx)=first 
N eop(jx)=last => 
4 2<=4<=256 A ca=4 A jx+D0 A 
Vy[(0<y<jx+1 A bop(y)>1 A O<eop(y)<4) > 
text (boply)-))-textteopl +) 
Vy[  (0O<y<jx*1 A “(eop(y)=0))= 
[string(bop(y), eop(y))=ok ^ bop(y)>=1 A eop(y)<=2 
ZVZ (O<zejx 1 A Alz=y)) 
=> ( “(bop(z)=bop(y)) ^ 
(bop(z)<bop(y) => eop(z)<eop(y))) J] IA 
Jy(y<jx*1 A l<=bop(y)<=current-1 A current<=eop(y)<=2 ) } 
The consequents of this verification condition are considered 
one at a time. 
a. 2<=2<=256 an ca-£ ^ 3x+1>0: 
these predicates are just a restatement of antecedents. 
b. My[(0«y«jx*l A bop(y)>1 A 0<eop(y)<2)=> 
= (text (bop(y)-1)=text(eop[(y)+1))]: 
the antecedent A40 (contained within assertion A49) establishes 
the generalization on y for O<y<jx. If the statement is true 
for y=jx as well, then this consequent is proved. The ante- 
cedents of the verification condition allow the generalization 
statement for y=jx to be written as: 
(first>1 A O<clast<2) => — (text(first-1)=text(last+1)); 
from the input assertion of this procedure it is known that 
(first=1 Y last= 4 V “(text(first-1)=text(last+1))); 


the generalization statement for y=jx has an antecedent which 
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negates the first two predicates of this disjunction; there- 
fore the third predicate, which is also the consequent of the 
generalization statement for y=jx, must be true. Thus this 
consequent of the verification condition is proved. 

c. Wy (O<y<jx+l A — (eop(y)=0)) => 

[string (bop(y) ,eop(y))=ok A bop(y)>=1 
A eoply)<=2 A Vz( [0S 24] XTl A. —(z2v)) 
=> (— (bop(z)=bop(y)) © | 
^ (bop(z)«bop(y) 7» eop(z)«eop(y))) )] ] 

The antecedent A41 (contained within A49) establishes the 
generalization on y for O«y«jx. If the generalization statement 
is demonstrated true for y-jx, then this consequent holds. For 
the case y=jx, the conditional which must be proved is: 

—(last=0) = [string(first,last)=ok A first>=1 

A last<= t A Yz(  (O<z<jx+1 A a(z=jx)) —(^(bop(z)sfirst) 

A (bop(z)<first => eop(z)<last)) )] 
The antecedent of the above conditional is clearly true; if 
the several consequential predicates are true, then the veri- 
fication condition consequent in question is proved. The first 
3 predicates follow from the input assertion. The fourth 
predicate, the generalization on z, has already been shown to 
be true for the range 0<z<jx 
(from entry=true A 1 (eop(jx)=0) A A50); 
further, if z=jx then 7 (z=jx) is false and the conditional 
which is the fourth predicate is true, 
This completes the proof for this consequent of the verification 


coneal tion. 
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d. JIy(y<jx+1 A 1<=bop(y)<=current-1 
A current<=eop(y)<=2): 
It is proposed that y=jx will satisfy this existential statement. 
1950 E 
bop(jx)=first A 1l<=first<=4-1 A first<last 
A current<=last A last<=2 => 

1<=bop(jx)<=current-1; 
eop(jx)=last A current<=last A last<=2 => 
current<=eop(jx)<=4; 
SO y=jx satisfies the existential statement, and this last 
consequent of the verification condition is shown. The veri- 
fication conditions for both cases on path A49-50 to AS1-52 


have been proved. 


14. Input Assertion. to. Output Assertion 


The proof of partial correctness for this procedure 
is completed by concatenation of paths A39-41 to A49-50 and 


A49=50 to A51-52. 


15. Termination 
The procedure has one entry and one exit, the only 


loop is a for statement; therefore, the procedure terminates. 


K. PROCEDURE MAIN 
Figure 8 contains the assertions for the main body of the 


example program. 


1. input Assertion: AD, 
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comment main; 
AO: (€ 2<=input(l)<=236 A ca=0 ) 
initiaiize; 
A3: (C 2<Xa3ic=256 A ca=9 A ¡x=i A 1t:80 A cb=biank ) 
read and write input cards; 
A16: C 2<=1=256 A casi X yx=1l ) 
palindrome check; 


A53: (€ 2G=1<=256 A caši A 3x0 ) 
A54: {€ Vx((2«-7x(31 ^ text(x-i)-text(x)) — 
Ayly< yx ^ i<=boply)<=x-i A x<=eoply)<=1))] ) 
A55: (€ Wx((3(=x(=i A text(x-2)=text(x)) => 
dyly< yx A i<tboply)<=x-2 A x<=eoply)<=i))] ) 
A56: ( Vyl(0< y<yx A bopíy)>i A Oteopíy)< 1) > 
~(texttboply)-i)=textleop(y)+1))] ) 
A57: € VYyl (By yx A ~Ceoply) =9)) => 
fatring(boply),eoply) )=ok A boply)>=1A eoply)<=i 
NYZ (Oz jx A "(z2y)) = 
(~(bop(z)=boply)) ^ Chop(z)<boply) => eopl(z)<eopfy))) )] ] ) 


if Jx*]1 then tezxt3 
else write_all._palindromes; 


A58: ( A53 A A84 A ASS “A A56 A A57 ) 


end. 


im 


FIGURE SS 


PROCEDURE MAIN 
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Z Output Assertion: A58. 


3. Intermediate Assertions: 

The I ernedsate assertions are assertions A3, Al6, and 
A53-57. They are precisely the input and/or output assertions 
of the procedure calls they precede and/or follow. The veri- 
fication condition path for assertion A0 to A53-57 is proved 
by repeated application of the rule of inference for procedure 
calls, and then by concatenation. The verification condition 
for path A53-57 to A58 is simply: 

{A53-57} non-significant statement {A53-57} , 
because the intervening if Statement merely prints the results 


which have already been proven correct; its proof is immediate. 


4. Termination 
All of the procedures called from this main body have 
been shown to terminate; this program has one entry, one exit 
and no loops; therefore, it terminates. This completes the 


proof of total correctness of the example program. 
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APPENDIX B 


APPLICATION OF DISTRIBUTED 


CORRECTNESS TECHNIQUES 


A. ASSUMPTIONS, ABBREVIATIONS, AND NOTATION 

In addition to the assumptions about the example program 
verified by static analysis (Chapter IV, Section A), it was 

further assumed that all input data read by the program were 

type compatible with variables and that the correct number of 
input characters were present in the input data stream. Integer 
arithmetic was also assumed. Because actual dynamic testing 
was involved, assumptions that the operating system and compiler 
operated correctly were at least partially verified during 
testing. 

Because several of the program variable names are verbose, 
the abbreviations listed below were used in presenting the 


assertions and their verification: 


-2 length+of+text 

-2t cardlimit 

Ec cardbuffer 

-n number+of+input+cards 
-© card+counter 

-bp bufferposition 

-bop begin+of+palindrome 
-eop end+of+palindrome 

-p palindrome 


Figures 9 through 12 are listings of four program procedures 
with labeled synthetic assertions inserted to aid the discussion 
of the correctness demonstration. Assertions BO and B29-33 are 
the input and output specifications, respectively. Assertions 


are contained within braces " { }," and in Figures 9 through 12 
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wherever successive labeled assertions follow a program state- 
ment, the intended synthetic assertion for that point is a con- 
junction of those assertions. Frequently assertions contain 
within the braces the names (labels) of other assertions; the 
meaning implied ıs a literal replacement of the label with its 
expansion. 

Condition tables in the following sections list on their 
left the several predicates which were considered to partition 
the input domain of the given program fragments. The columns 
to the right of the predicates list the conceivable combinations 
of truth values for the several predicates. Corresponding to 
each column, a test data element was selected to verify program 
operation for each composite predicate (conjunction of the truth 
value entries in each column). The following entries were used 


ın the columns: 


y Yes, or ‚true, 

n No, or false. 

- : Don't care; either true or false. 

(y) Required to be true by the value for 
another entry in the same column. 

(n) Similar to (y), except false. 


B-SEUTILITY PROCEDURES 

The procédures "textl, "text, — texto, “blankelines,” 
and "write+all+palindromes' do not affect program performance 
of the output specification. (They effect the neat printing 
of the results obtained in the significant procedures,) As in 
the presentation of the formal proof for the example program, 
these procedures will not be examined here. However, it should 


be noted that because the method reported in this appendix 
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involved actual program execution, a side effect of the tests 
performed was to verify the performance of these non-essential 


procedures, 


C. PROCEDURE MAIN 

The methodology using the principle of distributed correct- 
ness and the condition table method for selecting test data 
(where needed) was first applied to the main body of the example 
program; procedure calls were treated either as an in-line ex- 
pansion of code or as program statements whose semantic meaning 
was defined by the input and output assertions of the called pro- 
cedure. It was assumed that the input assertion BO is satisfied 
when program execution begins. Figure 9 contains the synthesized 
assertions for this procedure. 


I Synthesized Assertion Bl: 
2<=2<=256 A jx=1 A 2t=80 A cb=blank 


a. Test Data Assertion and Verification 
The test data assertion is that for g=2 and for any 
corresponding character string (of length 2), the synthesized 
assertion is valid. Verification was obtained by executing the 
program statement "initialize;" preceeding assertion Bl with 
input data =2. 
b. Generalization Assertion and Verification 
The generalizatlon assertion is that for any input 
data satisfying the input assertion B0, the same result as above 
will be obtained. Verification is made by static analysis of 


procedure "initialize" - the assignments satisfying Bl are 
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comment main; 

BO: 1 2<=1<=256 ) 
inltlallze; 

Bl: ( 2<=1<=256 A Jx71 A 1t780 A cb=blank ) 
read and write. input cards; 

B5: € 2<=1<=256 A cal A Jx*1l ) 


palindrome check: 
if Jx*1 then text3 
else wrlte_all_palindromes; 


B29: ( 2<=1<=256 A ca-1l A jx?>0 ) 
B30: ( Vx[(2<=x<=1 A textíx-1)=textíx)) => 
syly< jx ^ 1<=bopíy)=x-1 A xt=zeopíiy)<=1)] ) 
B31: ( Vx[(3<X=x<=1 A text(x-2)=text(x))—> 
Jyly<jx A I<=boply)<=x-2A xzeop(y)<=1)] ) 
B32: ( Vyl[(0<y< yx A bopíiy)>i A O0teopíy)< 1) => 
~(text(bop(y)-L)=text(eoply)+1))) J 
B33: € Vyl (0«yXJx ^ ^(eop(C y)290)) 5 
Cstring(boply) ,eoply))=ok A bopíy)>=1 A eoply)<=1 
AYUzZ( (0<Xz<Jx a (z7y)) => 
(“(bopíz)=bopíiy)) a (bopíz)<bopíy) => eoplz)<eop' y))) 21 ] ) 


end. 


FIGURE 9 


PROCEDURE MAIN 
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executed unconditionally. 
c. Proof of Synthesized Assertion 

The synthesized assertion follows directly from 
the test data and generalization assertions. Note that the 
procedure call "initializes" was treated as an in-line sub- 
stitution of code. The proof of Bl amounted to a demonstration 
of correctness of the procedure "initialize." 

2. Synthesized Assertion B5: 
2<=4<=256 A ca=4 A jx=l 

The control path from assertion Bl to B5 contains only 
a procedure call to “read+and«write+input+«cards"; assertion B5 
is proved by showing that it is equivalent to the output speci- 
fication of the procedure. 

Let assertion B2 be identical to Bl, and let it be the 
input assertion for procedure "read-and-write-input-cards" (see 
Figure 4 in Appendix A); clearly B2 holds since Bl precede the 
procedure call and has been shown true. Examination of the 
procedure reveals that the predicates 2<=2<=256 and jx=1 are 
not modified in its execution; only the predicate ca=2 (which 
as before means that "ZZ" characters have been properly read 
from the input stream and assigned to the string variable "text" 
in the proper position) remains to be shown. This will be 
done by verification of the output assertion for the procedure 
called. 

a. Synthesized Assertion B3: 

Let B3 be an assertion inserted following the 


first statement in "read+and+write+input+cards" 
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(n:=((2-l)div %t)+1;). The assertion is that: 
"n" is the correct number of 
input cards for the characters 


in a string Oof length "4" 


The test data assertion for B3 was determined using the 
following condition table to divide the input domain into 


equivalence classes: 








Predicate 
2<=2<= 80 y (n) (n) (n) 
81<=4<=160 (n) y (n) (n) 
161<=4<=240 (n) (n) y (n) 
241<=2<=256 (n) (n) m) y 
Test data (2) 2 81 240 256 
Correct value (n) 1 2 3 4 


The test data assertion (i.e., that the program will execute 
properly for the test data elements identified in the preceding 
table) was verified by execution of the program to assertion 

B3 with the four test data values of ''2" and checking for the 
assignment Ot the correct value to "n", 

The generalization assertion at B3 is that n is totally 
determined by the four predicates on "2' given in the condition 
table; from the program statement "n:=((%-1)div &t)+1" and the 
predicate 2£t=80 it is apparent that this is so. 

The proof of the synthesized assertion B3 follows directly 
from the test data and generalization assertions and Theorem 2.1 
of Reference 14 (the theorem states that if two functions on 


the same domain D are totally determined by the same predicates, 





then those predicates partition D into equivalence classes for 
testing purposes). Theorem 2.1 applies in this case as the 
program performance (first function) and the assignment algorithm 
(second function) are both totally determined by the four pre- 
dicates on "2." 
b. Synthesized Assertion B4: 

Let B4 be inserted following the last statement in 
procedure "read+and+*write+input*+cards" (ives the output 
assertion for the procedure). The assertion is: 


ijx=2+1 A ca=2 


The test data assertion for B4 was determined using 
the following condition table to divide the input domain into 


equivalence classes: 





Predicate 
2<=2<80 y n n n 
2<=2<=256 A 2 rem80=0 (n) y y n 
80<2<=256 (n) n y (y) 
n=1 (y) (yY) 1n) (n) 
n> l (n) (n) (y) (v) 
Test data (9* 2 80 160 81 
Correct value (ix) 3 81 161 82 


*An input string of "2' characters must 
also be provided. 


The predicates listed above are those which were presumed to 
have all possible bearing on program operation; note that the 
two predicates on "n" were actually unnecessary since "n" is 


totally determined by "2." 


137 








The test data assertion is that the correct results will be 
obtained for the four test data elements identified in the con- 
dition table; verification was successfully performed by program 
execution. 

The generalization assertion at B4 is that 1x is totally 
determined by the three predicates on "4" listed in the condition 
table (and "ca" is one less than ix). This was verified by in- 
Spection of the program statements bene assertions B3 and B4. 

The proof of the synthesized assertion B4 follows directly 


from test data and generalization assertions and Theorem 2.1 (14). 


C. Proof of Synthesized Assertion BS 
It has been shown that assertion Bl preceding the 
call to procedure "read+and+write+input+cards" satisfies the 
input assertion for the procedure, and that the procedure 
correctly assures the validity of its output assertion (B4). 
Since B4 requires that ca-2, synthesized assertion B5 is shown 
by the distributed correctness of the called procedure. 
3. Synthesized Assertion B29-33 

The assertions B29-33 are the output specification for 
the example program. The only significant program statement 
intervening between assertion B5 and B29-33 in the main program 
is a call to procedure "palindrome+check" (Figure 10 is a listing 
of the procedure). Note that assertion B5 satisfies the input 
assertion (B6-8) to the procedure (because B6 is a restatement 
of B5 and the conditionals which constitute assertions B7 and B8 


have antecedents which are necessarily false when jx=2; therefore 
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the conditionals are true) and that the output assertion of the 
procedure (B12) is identical to assertion B29-33. Therefore, 

if the distributed correctness of procedure "palindrome+check" 
1s shown separately and if the procedure call statement is exe- 
cuted for the test cases identified in the verification of the 
procedure, then the synthesized assertion B29-33 is demonstrated 
to be true, and the verification of the main program is complete. 
The correctness of the called procedure is demonstrated in the 


next section. 


D. PROCEDURE PALINDROME CHECK 
Figure 10 contains the synthesized assertions for this pro- 
cedure. Similar to the way correctness of the main program was 
verified by relying on the distributed correctness of this pro- 
cedure, this procedure will be verified by relying on the dis- 
tributed correctness of the procedure which it calis, namely 
"continue checking." 
1. Synthesized Assertion B6-8: 
B6: 2<=4<=256 A jx=l ^ ca-£ 
B7: Y y[(0<y<jx A boply)>1 A O<eop(y)<2) => 
— (text(bop(y)-1)=text(eop(y)+1))| 
B8: Vy[  (0<y<jx A =Ñ(eop(y)=0)) => 
[string(bop(y) ,eop(y))=ok A bop(y)>=1 A eop(y)<=% 
a Yz (0<z<jx A T(z=y))=> 
(^ (bop(z)-bop(y)) 
A (bop(z)<bop(y) => eop(2)<eop(y))) JI) 
Synthesized assertion B6-8 is the input assertion for the 


procedure. Static analysis of the program reveals that the 
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procedure 
comment f 
begin 


palindrome_check; 
ind ail paiindromes within given text string; 


comment scan text from left to right; 


B6: C 2<=1<=25 
BG: € Yy[ (0< y< 
^( text( 


6 ^ JX*i ^ ca=l 3 
JZ A boply)>1 A O0Ceop(y)X 1) => 
bopl(y)-i)=text(eop(y)+i))] ) 


B8: C Vyl (8<Cy“jx A ~Ceoply) =O) ) => 
Catring(boply) ,eoply))=0k A boply)>=IA eoply)<=i 
A Val (Oz jx A ~Czzy)) => 


( 


for Ix:=2 
begin 
if te 
B9: C 2721725 
B10: C text(Cix- 


^ string 


if ix 


Bii: € B9 ^. tex 
^ string 


end; 


~(bop(z)=boply)) A (bop(z)<boply) =) eop(z)‘eopl( y))) 
step i until iength_of_text do 
xt(ix-1) - text(ix) then 
6/7. jx?0 ^ ca-i^ B7 ^ B8 ) 
i)*text(ix) ^ start-ix—i ^ finish? lx 
(ix-1i,1ix)=ok MA ic=zix-i A ixl=!I ) 
continue checking(( ix-1i),ix); 
~= 2 then 
if text(ix-2)=text(ix) then 


t(ix-2)=text(ix) A start=ix-2% finish=izx 
(ix-2,ix)-ok A 1l<=ix-2 A íixt=1 ) 


continue checking((ix-2),ix); 


B12: € 2<=1£=7256 A ca=l A jx>0A B3808 A B3i A B32 A B33 ) 


end palindrome check; 


FIGURE 10 


PROCEDURE PALINDROME+CHECK 
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only call to procedure "palindrome+check" is the call in "main" 
following assertion B5; assertion B5 is identical to B6, there- 
fore B6 holds at the time of the procedure call. B5 ensures 
that jx-1, and because there is no integer y such that 0<y<l, 
the antecedents of the conditionals which constitute B7 and B8 
are necessarily false at the time of the procedure call. There- 
fore the conditionals must be true at this point, and the input 


assertion to the procedure is satisfied whenever it is called. 


| 2. Synthesized Assertion B9-10: 
B9: 2<=2<=256 A jx>0 A ca=2 A B7/ A BŠ 
B10: text(ix-1)=text(ix) A start=ix-1 ^A finish=łx 


A string(ix-1,ix)=0k A l<=ix-1 A ix<=4 


The assertion B9-10 is inserted to state that the input 
specification is satisfied for the procedure "continue+checking," 
which is called immediately following Ehe assertion. All pre- 
predicates of B9-10 are a restatement of the input assertion 
B6-10 (and have not been modified by the intervening program 
statements) except: 

a. text(ix-l)=text(ix): 
this predicate is assured since control reaches 
B9-IU only Lilt 15 satisfied (preceding it statement). 
b. start=ix-1 A finish=ix: 
these predicates are true by definition; "start" 
and "finish" are constants, initialized to the values with which 
"continue+checking" will be called, which are used in the 


proofs of synthesized assertions. 
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cor EStrINSUIXx-1,.J2X)90k. 
follows immediately from text(ix-1)=text(ix). 
d. «^0 A BF A Be: 
these predicates hold on the first loop iteration 
because of the input assertion; they hold on subsequent itera- 
tions due to the distributed correctness of "continue checking" 
(they are contained within the procedure's output assertion). 
The preceding discussion reveals that the synthesized 
assertion B9-10 is always valid; thus no test data and generali- 


zation assertions are required. 


2. öyithesized Assertion B11: 
ETI: B9 A text(ix-2)=text(ix) A start=ix-2 A finish=ix 


^ string(ix-2,ix)-ok ^ 1<=1x-2 A ix<=2 
The assertion B11 is inserted to state that the input 
specification is satisfied for the procedure "continue+checking," 
which is called immediately following the assertion. In a 
fashion similar to that discussed above, it may be verified that 
assertion Bll always holds, and no test data and generalization 


assertions are required. 


4. oynthesizéd Assertion blz: 
ZEN 255 A caa A. X20 A B30:A BSL A B32 A B353 


Assertion B12 is the output assertion for procedure 
"palindrome-check"; the expansions for assertions B30 through 


B33, which are predicates of assertion Bl12, are given below: 
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B30: Vx [(2<=x<=2 A text(x-1)=text(x))=> 
Jdy(ysjx ^ 1<=bop(y)<=x-1 A x<=eop(y)<=%)] 
B31: Yx[(3<=x<=2 A text(x-2)=text(x)) > 
Sy (y<jx A 1<=bop(y)<=x-2 A x<=eop(y)<=2)] 
B32: Wy[(0<y<xj A bop(y)>1 A O<eop(y)<4) => 
“(text (bop(y)=1)=textleoply) +1) )] 
B33: Vy[ (0<y<jx A 7 (eop(y)=0)) => 
[string (bop(y) ,eop(y))=ok A boply)>=1 A eoply)<= £ 
^Mz( (0«z«jx ^ 7 (z=y)) => 


(—(bop(z)=bop(y)) A (bop(z)<bop(y) =eop(z)<eop(y))) )] ] 


The truth of assertion B12 may be verified partially-through 
logical techniques and partially through dynamic testing. By 
Static analysis it is noted that if during execution of the 
procedure no statements which call "continue-checking" are 
actually executed, then all the predicates of assertion B12 are 
merely restatements of the input assertion B6-8 and are not 
modified by program execution (no positive processing takes 
place). 

If calls to "continue-checking" are executed, then from the 
output assertion of that procedure and the principle of distri- 
buted correctness (the demonstration of correctness and a listing, 
Figure 11, of that procedure are presented subsequently), the 
following predicates remain unchanged by execution of the pro- 
Gedure: 

2<=2<=256 A cast A JX>D A B32 “~ BSS 
The predicates B30 and B31 will be demonstrated through 


testing in the following manner. If "continue<+checking" is 
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called with actual parameters "start" and "finish", then its 
QUEPUE assertion Verifies that: 
dy (0<y<jx A 1<=bop(y)<=start A finish<=eop(y)<=2) 
Predicates B30 and B31 are verified, and thus so is the syn- 
thesized assertion B12, if it is shown that: 
Vx(2<=x<=4 A text (x-1)=text(x) => 
"continue*checking" is called, 
with start=x-1 and finish=x; and 
Yx(3<=x<=2 A text(x-2)=text(x) > 
"continue+checking'" is called, 


With start=x-2 and finish=x. 


a. Test Data Assertion and Verification 

It was presumed from static analysis of this proced- 
dure that if procedure calls are correctly mode to "continue- 
checking" for the first three characters of a text string, 
they will be correctly made for all characters. (Only the 
character patterns over a sub-string of length three are examined 
by the statements which determine whether and when to call 
"continue*checking".) Thus test data were selected to consider 
all possible conditions arising in the first three characters. 


A condition table was prepared as follows: 
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Predicate 


£22 ^ 1x=1 y n n n n n n n n n n 
$22 A ix=2 (n) y y n n n n n n n n 
£=3 A ix=l Mi (n) ns y n n n n n n n 
0=3 A x52 (n in) al (n) y y n n n n n 
4=3 A jx=3 (n) (n) (n) (n) (n) (n) y y y y. y 
cext(1)=text(2) y n - y n y y n n n 
ee text(3) - - - - - - y n y n n 
text(2)=text(3) - = - - - =) (ye n) (nom y 
Test Data: (2) * 2 2 * 3 3 5 3 3 3 3 
(text) bb ab bbb aba bbb bba aba abc abb 


*These compound predicates cannot be satisfied 
for any input data values. 

The preceding condition table identifies seven unique test 
data elements which were input to the program for. dynamic testing. 
Correct results were obtained for all elements; the correct re- 
sults were defined as being the recording in the arrays "bop" 
and "eop" of entries which included those character positions 
corresponding to all truth values of "y" in the three rows of 


Predicates on text. 


b. Generalization Assertion and Verification 
The generalization assertion is that the preceding 
predicates totally determine the procedure calls made to 
"continue+checking", and thus the results recorded in the arrays 
"bop" and "eop". Verification of this assertion was not 
formally stated; verification relies on the thoroughness with 


which the applicable condition table was prepared. 


c. Proof of Synthesized Assertion 
The synthesized assertion follows from the 


discussion preceding the presentation of the applicable 
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condition table and from the test data and generalization 
assertions. Sufficiently general theorems to formally state 
a proof of the assertion were not available or forthcoming 
from this effort; however, the careful analysis of predicates 


built a high confidence that the program fragment is correct. 


E. PROCEDURE CONTINUE+CHECKING 

Figure 11 contains the synthesized assertions for this pro- 
cedure. The input assertion is B13-16; since it was verified 
in the preceeding section that this assertion was satisfied for 
all calls to this procedure, it will be assumed that this 
assertion is satisfied at the time of invocation of this pro- 


cedure. 


1. Synthesized Assertion B17-18: 
Bl7: BLI3 -^A Bl4 A BIS 


B18: text(first)=text(last) A 1<=first<=start 
A finish<=last<=2 ^ string(first, last)=ok 
A (finish=start+1 Y finish=start+2) A 


(first-l v Ilast-* V A(text(first-1)=text(last+1))) 


a. Test Data Assertion and Verification 
Test data were selected using the condition table 
method to consider all predicates which were considered to 
have a bearing on program processing with respect to assertion 
B17-18. The applicable condition table is presented below, in 


two sections, 


146 





procedure continue_checking (Integer value first, last); 

comment Given first and last as pointers to a palindrome 
of slze 2 or 3, this procedure checks whether or not this 
palindrome Is included in a larger palindrome; 

begin 


B13: ( 2<=1<=256 A ca=zl A yx?29 ) 
B14: ( Vyl(0 yx A boply)>1 A O<teopíy)<1)=> 
e( textíboply)-1)=textleopíly)+1))] ) 
| Bl5: (C Yyl (0€yXJx ^ ^(eop(Cy)20))—7 
[string( bop( y?) ,eopíly))=0k A bopíy)>=1 A eopí y)<=1 
AVz (0tz< yx A “lz=y))=> 
(“(bopíz)=bopty)) A (bopíz)<bopí y) => eoplz)eop: vd)» )] J ) 
B16: ( text(first)=textí last) A start=first A finlsbx= last 
A string(first,last)=ok A l<=start A finish<=1 
^(flnish*start*] V finish-start-*2) ) 


logical palindrome; 
palindrome:-true; 
while ((first>1) and (last<length of. text) and (palindrome“ true)) do 
begin 
1f text(flrst-1) * text(last*]) then 
begin 
comment larger palindrome found; 
first:-first-]; 
last:=last+1; 


end 
else 
begin 
palindrome:-faise; comment largest palindrome found; 
end; 
end; 


B17: (€ B13 ^A B14 A B1S ) 
B18: (€ textíflrst)=textí(last) A I<=firstí<=start A finsih =lastí= 
A string(first,last)=-ok A (f Inlsb=start+]1 Y finish=start+2) 
A (first=] v last=l Y »(text(first-1)=text(last+ti))) ) 
record_palindrome(first, last); 


B19: (C BIS A Bi4 A B15 ) 
B20: € dy(@<y<yx A lX=boply)<=start A finish<=eop(y)<=1) ) 


end continue. checking; 


FIGURE LI 


PROCEDURE CONTINUE+CHECKING 
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Predicate 


start+l=finish 
startr2=finish 
start=1 
start=2 
start>2 
finish=2 
finish=2-1 
finish<4-1 
text(start-1)- 
text(finish+1) 
text(start-2)= 
text(finish-*2) 


lest Data: 
(text) 


(2) 


*These compound predicates cannot 


y y 
) tn) (n) = 


y y 

ota) Ha = 
Min) i) 
n n n 
y n n 
CIL ae 


a V y 
(ba (n) in) 
n n n 
JERSEY 
(n) (n) (n) 
y n n 
Mi y y 
(ma) (a) (n) 


Í -e ~ ans «ETA UA, ae a A eed. 


2 3 4 * 
aa aab aabc 


for any input data values. 


Predicate 


start*l-finish 
start+2=finish 
start=1 
start=2 
Sparro? 
finish=2 
finish=4-1 
finish<4-1 
text(start-1)= 
text (finishtl) 
text(start-2)= 
text(finish+2) 


Test Data: 
(text) 


(2) 


A: abbad 
Et = abeccd 


The preceding condition table identifies 


B: 
F: 


y 
(n) 
n 


ee ll— 2. 


abb cd 
apccba 


be 
y VM 
(n) (n) (n) (n) 
n n n n 
y n n n 
(n) y y y 
n n n 
non) y cy 
VICUS Cnm) 
n - y n 
5 4 5 5 
B C D E 
C: CODO 
G: 3b5GCBd 
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3 4 4 
abb abba abbc 
satısfied 

y y yY 
(n) (n) qm) 

n n n 

n n n 

y y X 

n n n 

n n n 

y y 7 

y y n 

y n = 

6 6 6 

F G H 

D:  abceceb 

H: abccde 


fourteen test 


data elements; these were used as input to the program for 








dynamic testing. Correct results were verified for all ele- 
ments by printing variable values following assertion B17-18 
and verifying that the predicates of the assertion were satis- 
fied. During presentation of the preceding condition table, 
no columns with an "n" entry for the first predicate and a "y" 
entry for the second were added because no new insights to the 


procedure's operation would have been gained. 


b. Generalization Assertion and Verification 
The generalization assertion is that the satisfaction 
of the synthetic assertion Bl7-18 is totally determined by the 
predicates of the condition table; the only verification was 
the analysis which served as a basis for the preparation of the 


table. 


C. Proof of Synthesized Assertion 
The synthesized assertion follows from the test 
data and generalization assertions. No formal proof could be 


offered. 


2. synthesized Assertion B19-20: 
B19: BIS A BI4 = BIS 


B20: 3y(0<y<jx A 1l<=bop[y)<=start A finish<=eop(y)<=2) 
Assertion B19-20 is the output assertion for this procedure. 
Inspection of Figure 12, the listing and assertions for proce- 
dure "record+palindrome'" reveals that assertion B17-18, which 
precedes the only call to that procedure, which call in turn 
precedes assertion B19-20, satisfies the input assertion to 


"record+palindrome", and further that the output assertion of 
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"record*palindrome" satisfies assertion B19-20. Therefore syn- 
thesized assertion B19-20 is verified by the correctness of 
"record+palindrome" (which is shown in the next section), and 


test data and generalization assertions are not required here. 


F. PROCEDURE RECORD+PALINDROME 

Figure 12 contains the synthesized assertions for this pro- 
cedure. The input assertion is B21-24; since it was verified 
in the preceding section that this assertion is satisfied when- 
ever the procedure is called, the input assertion is assumed 


to hold at procedure invocation. 


l. =SymtehesızedsAssererongB2>: 
BZ1 A B22 A B23 A B24 A entry=true 


a. Proof of Synthesized Assertion 

The test data and generalization assertions are 
simply the observation that any and all input data will cause 
the execution of the statement assigning "entry" equal to true; 
the rest of the assertion is a restatement of the input asser- 
tion, none of which has been modified. Verification was post- 
poned until the verification of the test data assertion for 
synthesized assertion B26. The proof of synthesized assertion 


B25 follows directly from this observation. 


2. Synthesized Assertion B26: 
(entry=false A B27 a B28) V 
[entry=true A B21 A B22 A B23 A B24 
ANz(0szsjx —>( 1(bop(z)=first 


^ (bop(z)«first =2eop(z)<last))] 
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B21: 
B22: 


B23: 


B24: 


B25: 


B26: 


B27: 
B28: 





procedure record-palindrome (integer value first, last); 


comment Record only max length palindromes. Flag 
recorded palindromes if they are included 
specifled by first and last. 


Jx was initialized to i. After completion jx points to the 
next entry in begin_of_palindrome and end. 


begin 


C 2<=1<=256 ^ cn*1 ^ jx29 ) 

C VyLCOCy« Jx ^ bopC y)? 1 A Keoply){1) = 
m(text(boply)-i)=textl(eoply)+1))]j 3} 

( VyE (Oc y& x ^ "CeopCy)30)) —2 


previous!v 


in the palindrome 


of_palindrome; 


Catring(boply) .eoply))=ok A boply)>=1 A eoply)<=1 


AVzl (8«z6Jx ^ "(z2y)) — 


(“( bopíiz)=boply)) A Chopl(z)<boply) = eoplz)<eopty))) )] 
( text(first)=text( laet) A l<tfirst<=start ~ finsih<=iast<‘=i 


A string(first,last)=ok A startfinish 


A (first=1 V last=lv ~(text(first-l)=text(last+i))) ) 


integer i; comme nt local counter; 
logical entry; 
entry:=true; 


C B21 A B22 A B23 A B24a entry=true ) 


for 1:=1 step i until Jjx-1 do 
begin 
if ((first>=begin._of_palindromeí(i)) 
and (last<=end._of_palindrome(i))) then 
begin 
corrent Palindrome is entireiy included 


in a previously 


recorded paiindrome. No entry required; 


entry:=false; 
end 
else 

begin 

1f ((begin. of palindrome( i) >= first) 
and (end. of_paiindrome(i) <= last)) 
begin 
end_of_palindrome( i) :=90; 
comment flag smailer pallndrome; 
end: 

end; 


then 


end; comment All previously recorded palindromes 


compared with last input; 


C (entry=false A B27 A B28) W 
[entry=true A B2i A B22 A B23 A B24 
A Yz(0<z<jx = (<(bop(z)=first) 
A bop(z)<first => eoplz) last)] I 
lf entry = true then 
begin 


comment larger than all previous or overlapping or disyeint; 


begin. of. palindrome( jx) :=first; 
end_of—_palindrome( jx) :=last; 
Jxr:=jyx+i; 

end; 


C 2G=1<=256 A ca*l1 A jx>8 A B22 A B23 ) 
C Sy( Oy yx A iC=boply)<=start A finish<=eoply)<=1) 


end record_palindrome; 
FIGURE 12 
PROCEDURE RECORD+PALINDROME 
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This assertion is a statement that either entry=false and one 
set of predicates apply, or that entry=true and another set 
apply. If entry=false, no further action will be taken in the 
procedure, and the output assertion is valid at this point. If 
entry=true, the input assertion is still valid, and the entry 
for the current palindrome, which will be the jx-th entry in 
"bop" and "eop", will only be disjoint or overlapping to all 
previous entries in those arrays for which the "eop" entry is 


not zero. 


a. Test Data Assertion and Verfication 
Test data were selected using the condition table 
method to consider all predicates which were considered to 
bear on the program processing with respect to assertion B26. 


The applicable condition table is presented below. 
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Predicate 


eop(i)=0 n n n n n n n n n y y y 
first>bop(i) y y y n n n n n n y n n 
first=bop(i) (a) (alun) y y y n noo n «nio n 
last«eop(i) y n n y n n y n n (n) (n) (n 
last=eop(1) AA aa ey AS AA) 

test data: E 
first 6 5 3 l 2 1 i 1 ik 6 I l 
last 7 9 4 5 3 9 2 3 5 7 3 9 
l 4 4 l D - 3 - - 1 l 1 1 
bop (i) 1 1 2 1 2 l 2 2 2 2 1 2 
eop(i) 9 9 3 4 3 5 5 5 5 0 0 0 
text B B B A 5 B ^ * B B A B 
X 5 5 2 3 - 4 - - 2 5 3 4 
correct 
action: X X - X X Y - x 7 Z Z - 
*These compound predicates cannot be 
satisfied for any input data values. 
A: aaaa Be baaabaaab 
X: Set entry = false 
n Set eop(i) = zero. 
2 None required, but program resets eop(i) = zero, 


which is permissable (eop(i) is already Zero). 
= As an action, means no action performed; entry 
remains true and a new entry will be made. 

The preceding condition table identifies two input Strings 
which were used as input data to the program; intermediate values 
of program values were inspected on each iteration of the for loop 
in procedure "record+palindrome' to determine when the compound 
predicates from the condition table were satisfied so that veri- 
fication of the correct action as specified in the table could 
be made. The correct action was observed for each test data 


element. 
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b. Generalization Assertion and Verification 
The generalization assertion is that the actions 
performed by the procedure are totally determined by the five 
Predicates in the condition table: if execution ot the for loop 
body performs properly for the identified test data elements, 
it performs properly for all data satisfying the same conjunctions 
of the five predicates. The verification offered is the analysis 


forming the basis for the condition table entries. 


c. Proof of Synthesized Assertion 

Since predicate B23 of the procedure input specifi- 
cation is validat the'entry to the tor Loop, 1t cannot happen 
thet the current palindrome (string (first, last)) both includes 
a previous entry and is included by a different previous entry. 
Since program action (either entry:=false or eop(i):=0) is taken 
only when one of these conditions exists, repeated execution 
from "i" equal 1 to jx-1 of the loop body cannot cause an unde- 
sirable result such as setting "entry" to false and also setting 
eop(i) to zero for some "i". Thus the synthesized assertion 
follows from the test data and generalization assertions, al- 


though a formal proof cannot be offered. 


3. Synthesized Assertion B27-28: 
B27: 2sm E250 A Ca KA IS VAT B22 97 225 


B28: Jy(0<y<jx A l<=bop(y)<=start A finish<=eop(y)<=4) 
Assertion B27-28 is the output assertion for this procedure. 


a. Test Assertion and Verification 


The test data assertion is that 1f the test data 
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elements identified in the first and sixth columns of the con- 
dition table used for assertion B26 are executed to the proce- 
dure's termination, the output specification will hold. The 
correct results were observed, namely that for the column-one 
element no new entries were made to the arrays "bop" and "eop", 
and that for the column-six element the proper (fourth) entry 
was made in the arrrays; in both cases the output specification 


was observed to hold. 


b. Generalization Assertion and Verification 
The generalization assertion is that the variable 
"entry' divides input to the procedure into two equivalence 
classes and that proper execution of one element of each class 
(as observed in the verification of the test data assertion) 


ensures proper execution for the entire class. 


c. Proof of Synthesized Assertion 
The synthesized assertion follows from the test data 
and generalization assertions; however, no theorem is available 
to formally prove the sets of input data identified are in 
fact equivalence classes. 

This verification of synthesized assertion B27-28 completes 
the demonstration of correctness of procedure "record+palindrome", 
The principle of distributed correctness has been applied to 
Show the correctness of the main program from the correctness 


of the called procedures. 
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